Message-ID: <299209945.8742.1414217237644.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_8741_1457143019.1414217237644" ------=_Part_8741_1457143019.1414217237644 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Recent email and blog activity have brought out the hardest area= to collaborate on: Data formats.=20
It seems silly that we are stuck on what should be a simple task; and mo= st of the reason we are stuck is over arguments on what makes a good featur= e model. Enough is Enough! Let's focus on slurping up the data; we won't ev= en bother to put it into a Feature yet. By taking it a step at a time we ca= n manage to work together first ...=20 =20 =20
For background (before we talk), have a look at how hibernate hoists stu= ff into it's a staging area (basically raw objects) before using those obje= cts to create a POJO and populate its fields.=20
If you look at the hibernate "UserType" you can just see how i= t is designed as a callback object for the staging area. The "data acc= essors" would be punting up raw arrays of primitive objects, and this = UserType part would be processing them into good objects for the cache.= =20
We have implemented a UserType for JTS Geometry previously.=20
So here is the Workflow:=20
So you can see the raw format combining 1 and 3 into a Range in the stag=
ing area. Using the information
in the staging area the complete feat= ure can be created.
There is a common GeoTools use case that involves doing a "sparse r= ead". When doing rendering we often want ask for "half of a featu= re" (maybe only the geometry and a single attribute are mentioned in t= he Style?). It will do us no good to read everything, and stage everything,= and then only use half of it=20 =20
In this case we only bothered to read the information needed for the tas= k at hand.