Hi Michaël,
As you might have guessed I have some interesting formats that don't fit
into the traditional flat model, so I'm having to come up with nice ways
to deal with these without automatically flattening them out too much.
Eventually we'll migrate this stuff to a database and then I can spend
some time to create a flatter model that works well.
For the "attributes" on the geometry I agree that normally attribution
should go on a feature rather than a geometry, there are some cases
where having it on the geometry is useful for processing or display. The
assumption here is that if you want to convert to a flat model you will
either accept these attributes are thrown away or will have to define a
mapping.
One of my cases is for Toponymy, I have a single feature that has
multiple text parts, each with their own orientation and styling. This
happens when you want to print a word on a curved line with control over
each letter but keep the items in the same feature. See below. By the
magic of UserData I can store the orientation, text height and text for
each point on a Point geometry and have the feature use a MultiPoint
geometry containing those points. I have this working with a custom
Style class.
W
o
r
d
The other case is where you want additional geometry types but don't
really need to create sub classes, e.g. AlignedPoint, OrientedLineString.
Paul
Michaël Michaud wrote:
> Hi again Paul,
>
> The only use cases I can imagine are
> - having specific attributes on each part of a geometry collection
> - programming stuff (don't know, maybe caching geometric information
> to improve performance...)
>
> otherwise, why do you want to put attributes on geometry and not on
> features
> The main problem in doing that is compatibility with widely used
> standards as shapefile, wkb, wkt...
>
> Michaël
>
> Paul Austin a écrit :
>
>> The current JTS Geometries have a UserData property which developers can
>> store a custom attribute on each geometry. This is really useful if you
>> have a data set which has additional information such as orientation for
>> a point or a direction of travel for a line.
>>
>> The one problem is that you can only store one value so you have to use
>> a Map as the user data to store more than one value. What would be
>> useful is if the geometry used a Map for the user data thus allowing
>> more than one value and simplifying user code as you don't have to cast
>> the userdata to a map.
>>
>> The following code demonstrates my preferred implementation, note that
>> the existing user data can still be used as it's just an entry in the
>> map and my using an EMPTY_MAP there is no extra memory required over the
>> existing user data approach if there are no attributes defined.
>>
>> private static String USER_DATA_KEY = "jts.userData";
>>
>> private Map attributes = Collections.EMPTY_MAP;
>>
>> public void setAttribute(String name, Object value) {
>> if (attributes == Collections.EMPTY_MAP) {
>> attributes = new HashMap();
>> }
>> attributes.put(name, value);
>> }
>>
>> public Object getAttribute(String name) {
>> return attributes.get(name);
>> }
>>
>> public Map getAttributes() {
>> return Collections.unmodifyableMap(attributes);
>> }
>>
>> public void setAttribute(Map attributes) {
>> this.attributes.putAll(attributes);
>> }
>>
>> public Object getUserData() {
>> return getAttribute(USER_DATA_KEY);
>> }
>>
>> public void setUserData(Object data) {
>> setAttribute(USER_DATA_KEY, data);
>> }
>>
>>
>> Any comments?
>>
>> Paul
>>
>> _______________________________________________
>> jts-devel mailing list
>> jts-devel@lists.jump-project.org
>> http://lists.refractions.net/mailman/listinfo/jts-devel
>>
>>
>>
>>
>
> _______________________________________________
> jts-devel mailing list
> jts-devel@lists.jump-project.org
> http://lists.refractions.net/mailman/listinfo/jts-devel
_______________________________________________
jts-devel mailing list
jts-devel@lists.jump-project.org
http://lists.refractions.net/mailman/listinfo/jts-devel
