[OSM-dev] RFC: map call to return deleted elements
steve at asklater.com
Sat May 23 00:29:58 BST 2009
Have you thought about the complexity of the algorithm? Hint.
It reminds me of the days before the current_nodes etc tables, where
all current and old data was in the same table for each object type.
The SQL and filtering to get all the nodes in a bbox, then see if they
were still actually within the bbox, sort, etc... was non-trivial.
On 22 May 2009, at 07:36, Matt Amos wrote:
> to make it easier to support undeleting and pre-upload conflict
> checking, it has been suggested that an API call (a "proper" API call,
> not AMF!) be written to allow the fetching of deleted items in a
> certain area.
> rather than write a different API call, i'm suggesting that the map
> call be modified to have an additional optional parameter
> "?visible=(true|false|both)", where true is the default, which
> controls whether visible items are returned, invisible ones, or both
> visible and invisible. here are the proposed changes to the effects of
> the call:
> 1) visible parameter not provided, or ?visible=true, or ?visible !=
> (false|both): same effects as previous versions of the map call: only
> visible nodes in the bbox or which share a visible way with those in
> the bbox are returned along with those visible ways and any visible
> relation which contains any of those nodes or ways.
> 2) visible=false: finds all non-visible nodes within the bbox,
> returning those and any non-visible ways which use them and any
> non-visible relations which use either the ways or nodes. non-visible
> items are returned as open XML elements with no tags, way nodes or
> relation members.
> 3) visible=both: finds all nodes in the bbox, returning those, plus
> any shared by ways (visible or not), plus those ways and relations
> (visible or not) which use any of those nodes or ways.
> comments, please :-)
> dev mailing list
> dev at openstreetmap.org
More information about the dev