As David points out, if a client has a use case where they need a map of
data, they can easily store their own implementation in the userData
field - that's what it's there for. I don't see a need to widen the JTS
API to support this special case.
And as Michael pointed out, it's probably not the best design to make
Geometrys carry a lot of attribution. That is the function of a Feature
model, which simply uses JTS objects to represent spatial information.
There's any number of those to choose from...
Adding this to Geometry would merely encourage the use of a
less-than-ideal model, IMO.
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
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
jts-devel mailing list
jts-devel@lists.jump-project.org
http://lists.refractions.net/mailman/listinfo/jts-devel
