[OSM-dev] Unusual large Changesets - Could OSM server API split uploaded data in more then one changeset?

Pierre Béland pierzenh at yahoo.fr
Sun Feb 9 14:33:10 UTC 2014


Hi Peter,

Then  a warning could be given in editors such as JOSM highlighting such edits that cover large zones.


 
Pierre 



________________________________
 De : Peter Wendorff <wendorff at uni-paderborn.de>
À : dev at openstreetmap.org 
Envoyé le : Dimanche 9 février 2014 4h59
Objet : Re: [OSM-dev] Unusual large Changesets - Could OSM server API split uploaded data in more then one changeset?
 

Hi Pierre,
as far as I know: no, that's not possible.
A changeset is not an atomic thing in OSM. It consists of a number of
tags (most often source and changeset if any) and a number of osm object
versions (nodes, ways and relations) and a bounding box.
This bounding box afaik is a boundingbox containing all objects edited,
but may be even larger.

Your propose the API to split this, but let's examine the following
counter example:

You are really editing a large area, let's say, you check a big part of
the coastline of a continent, let's say Europe.
You loaded the coastline into the editor and then start working on
fixing several gaps and bugs in it, going through a list of errors
returned e.g. by some coastline-checker tool.

Let's say this list is not ordered along the coastline. Instead you fix
the first error at the north sea coast of Latvia, then another one in
Greece.
After these two you decide to upload the first chunk of your changeset,
but not to close it (which is possible!).

The changes are online and valid immediately, and therefore they have to
have a changeset id they belong to. Thus at this point in time the API
has to decide to split these two edits to two changesets or not.
According to anything known up to know the changeset would be splitted,
but in the following hours you fix hundrets of other errors in the
coastline, and in the end every few kilometers there's an edit.
Would you have done it in a different order, the API wouldn't have split
the changeset at all, but now it's too late, many data consumers already
have pulled the first edits of your changeset, stored them under the
changeset ID the API decided at first.

Nevertheless I think you write about something which would indeed be
very useful, and that is to split the visual bounding boxes of one
changeset into several parts.

Currently each changeset is visualized as one big bounding box, but
instead it would in fact be much more useful to e.g. visualize it as all
affected tiles. Your changeset would then appear as two blobs of color,
one small box in Mali and another one in Bolivia.

But that's not a problem of the API and of the Changeset Bounding box,
but of the Visualization of Changesets and the algorithm pascal uses to
calculate the activity area.
It's the only simple way to get the activity area, as the bounding box
is the only coordinate to get by changeset without inspecting every
element inside, so it's a perfectly valid way to go, and it works most
often.
Inspecting further would require the API or the consuming application
(eg. wdyc and Pascals contributor statistics) to do much more work, and
it's the question if that's worth it.

regards
Peter


Am 08.02.2014 20:17, schrieb Pierre Béland:
> See changeset where editing only in bottom left corner and upper
> right corner http://www.openstreetmap.org/changeset/20447101
> 
> The bbox of the changeset above is not very instructive of the zone
> covered by this edit.  I updated one way in Mali. Then forgot to save
> before I moved to Bolivia for other editing again in a small area.
> 
> For example, if I look at contributor statistics for Bolivia with 
> Pascal Neis new Contributor statistics by a specific comment, I see a
>  small box for Bolivia, and a large box covering two continents,
> simply due to this single changeset. 
> http://resultmaps.neis-one.org/osm-changesets?comment=hotosm-bolivia
> 
> Such large bbox create problems when we want to analyse Contributor
> activities in one area extracting Changesets for a particular bbox.
> It is also difficult to assure follow-up of activities in a local
> zone you take care of.
> 
> To correct this problem, could the OSM API that take care to upload
> data to the OSM database analyze such Changesets that cover a large
> zone, in particular more then one continent, and split them if
> necessary in more then one changeset?
> 
> 
> 
> 
> 
> Pierre
> 
> 
> 
> _______________________________________________ dev mailing list 
> dev at openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
> 


_______________________________________________
dev mailing list
dev at openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20140209/00f28824/attachment.html>


More information about the dev mailing list