Am 09.02.2014 15:33, schrieb Pierre Béland: > Hi Peter, > > Then a warning could be given in editors such as JOSM highlighting such > edits that cover large zones. Yes, that would be useful. Nevertheless it's nothing in the API, but in the Editors.
regards Peter > > > > Pierre > > > > ________________________________ > De : Peter Wendorff <[email protected]> > À : [email protected] > 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 >> [email protected] https://lists.openstreetmap.org/listinfo/dev >> > > > _______________________________________________ > dev mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/dev > _______________________________________________ dev mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev
