On Jan 7, 2012, at 5:29 PM, Mark Coletti wrote:

> So, these are the changes I plan to make:
> 
> 	• Eliminate the MasonGeometry user data field redundancy; prefer to use the underlying JTS Geometry user data field.
> 	• The user data field should be just that: for the users.  Move the attribute information to a separate field that does not rely on the optional user data field.  As a pleasant by-product this also eliminates the originally mentioned exception problem.  (It's always a Bad Sign when one must suppress compiler warnings regarding unhandled exceptions, which is what we have now.)

I'm wondering about this though.  The attributes, commonly stored in geometry files, are automatically loaded by JTS into the JTS geometry user data, aren't they?  Wouldn't moving them elsewhere be going against JTS convention, and if this is the case, would it eventually bite us down the road?

> 	• Use a hash map instead of a manually sorted list for attributes thus eliminating the aforementioned brittleness.

Hashmaps will be a problem because they're not in a predictable sort order.  Maybe a ThreadedHashMap?

Sean