David,
That is what I am doing now.
With my suggestion there is no additional memory requirement over the
existing model and only a small overhead on users of the existing user data.
Paul
David Zwiers wrote:
> Paul,
>
> What's preventing you from placing a hashmap in each geometry as your user
> object? -- thus your code could be of the form
>
> Object o = ((HashMap)g.getUserData()).get('X');
> ((HashMap)g.getUserData()).set('X',o);
>
> Although this isn't perfect, this avoids performance hits (memory/access
> time) for apps which rely on quick access (aka. visual renderers).
>
> David
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Austin
> Sent: June 7, 2007 12:15 PM
> To: JTS Topology Suite Development
> Subject: Re: [jts-devel] Map for UserData
>
> 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
>
>
> _______________________________________________
> 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
