[osmosis-dev] API 0.6 and unique keys

[Brett Henderson]

marcus.wolschon at googlemail.com wrote:
> On Wed, 28 Jan 2009 21:09:26 +1100, Brett Henderson <brett at bretth.com>
> wrote:
>   
>> marcus.wolschon at googlemail.com wrote:
>>     
>>> I just learned on OSM-dev that in 0.6 you can no longer
>>> have more then one value for any key on an entity.
>>>
>>> Any chance we can use this to replace the Tag-class with
>>> a simple read-only Hashtable in the v0_6.Entity -class?
>>> It should simplify a lot of code and be much faster for
>>> accessing key-values for known keys.
>>> e.g. looking up the "highway"-attribute of a large number
>>> of ways now requires you to iterate over all attributes of
>>> all these ways in O(m+n) time whereas we can reduce this
>>> to O(m) -time and even end up with much simpler code.
>>>   
>>>       
>> Yeah, makes sense.
>>     
>
> A TreeMap may prove usefull here. It is a SortedMap.
>   
Cool, I haven't used that before.  It might solve the problem nicely.  
Perhaps it isn't a good idea to be relying on consistent ordering in 
tests but it certainly makes them a lot simpler :-)
> BTW: The Entity-classes could well use usefull toString()
> -methods. ;)
>   
Agree :-)
>> Out of curiosity, what were the main changes that took the time?
>>     
>
> Way.addNode()
> Entity.addTag()
> Relation.addMember()
>
> I usually filled them after creating all entities, sometimes in loops
> and had to completely reorder the code.
> Also handling relations in the LevelOfDetail-DataSet (combining
> and simplifying very, very long ways) had to be rewritten as
> I was often modifying the member-list of relations while
> recursively handling the case that an existing relation is detected
> while collecting the ways belonging to a long street/coastline/... .
>   
Hmm, so if I go back and add those methods again I'll be very unpopular :-)

Have you tried the EntityBuilder classes?  They were intended to make 
this easier, or at least require less code.  The builder classes can be 
used in place of normal entity classes where you require a mutable 
object and only convert them to a true entity at the interface of your 
task.  It is something of an experiment though.  If they're never useful 
then I might scrap the idea.  I've used them in a number of places 
within the core osmosis tasks.  The database code uses them extensively 
because the code that reads basic entities is quite separate from the 
code that reads tags, way nodes, etc so it's useful to be able to build 
an entity up in stages.