[OSM-dev] OSM without segments - prototype

[Brett Henderson]

If API scalability is an issue, the most effective change I can think of 
would be to allow a set of changes to be made via a single API request.  
This would correspond to a single HTTP request/response each time you 
hit the update button in JOSM.  This would drastically reduce the number 
of request/responses through the web server and *if* we were using a 
database with full transaction support it would reduce database load by 
grouping changes into single transactions.

I'm getting way ahead of myself but if we can agree on a common xml 
changeset format it would provide a useful transport format.

Just my two cents ...

bvh wrote:
> On Sun, Aug 19, 2007 at 01:01:23AM +0200, michael_j at email.de wrote:
>   
>> Removal of the segments should reduce the traffic sufficiently. As the API gets now slimmer some functionality might now be moved from the editor to the database. This should further reduce the traffic and also reduce the editor complexity. 
>> Particularly I consider splitting and merging ways might be useful to be handled at the server. 
>>
>> E.g.:
>> - Spliting ways:
>>    + SplitWayRequest (WayID-A, NodeID-A, NodeID-B) 
>>    + SplitWayResponse (WayIDofPartA, WayIDofPartB)
>>
>> - Joining ways or closing one way:
>>   + JoinWaysRequest (WaysID-A, NodeID-A, WayID-B, NodeID-B)
>>   + JoinWaysResponse (WayIDofJointWay)
>>     
>
> I don't think this will have a significant impact on server traffic.
> Generally the user will split/merge ways as part of a reorganization
> and is also likely to change some tags etc... I think JOSM and (certainly)
> Merkaartor are smart enough to combine those operations when possible.
>
> For an online editor like potlatch it might reduce complexity but for
> I know for certain that using such a call in Merkaartor will increase
> complexity (due to the logic that compresses multiple updates into one)
>
> So I don't think I'd use such a call if it became available.
>
> cu bart
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>