Re: [OSM-dev] OSM XML declaration, JOSM, Osmosis et al.
> Is Overpass so geared for tools that don't care about > uid/date/version/visible etc? Actually, yes. Note that these tools include map rendering, routing, location based search and probably every other tool that consumes the data. The data model is: the state of the Planet database (or an excerpt) at a fixed point in time, which makes perfectly sense. Even keeping a database up to date would be possible without meta data: It suffices to know the timestamp of the patches as a whole, not of every individual element, despite the behaviour of possibly picky tools. The old XAPI had mainly been suffering from a permanent shortage of hardware ressources. You now get a switch to download data three times faster if you omit data that you discard anyway later - if you render a map, do routing, or a lot of other useful things. This would even lower the burden on the still hardware-constrained Overpass API server. A lot of users encounter that useful but some can't make sense of the error messages somewhere later in the toolchain. I can't and I won't rewrite every tool, but I can happly write in the header whatever the tools expect. I simply asking for a consensus for the things to write in the header. Discussing the usefulness of the current history model is a different question. As I got never an answer to an earlier post on that topic http://lists.openstreetmap.org/pipermail/talk/2011-September/060027.html (it's [osm-talk], I'm sorry), I assume that history is only a minor concern to most users. Cheers, Roland ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM XML declaration, JOSM, Osmosis et al.
> Is Overpass so geared for tools that don't care about > uid/date/version/visible etc? Actually, yes. Note that these tools include map rendering, routing, location based search and probably every other tool that consumes the data. The data model is: the state of the Planet database (or an excerpt) at a fixed point in time, which makes perfectly sense. Even keeping a database up to date would be possible without meta data: It suffices to know the timestamp of the patches as a whole, not of every individual element, despite the behaviour of possibly picky tools. The old XAPI had mainly been suffering from a permanent shortage of hardware resources. You now get a switch to download data three times faster if you omit data that you discard anyway later - if you render a map, do routing, or a lot of other useful things. This would even lower the burden on the still hardware-constrained Overpass API server. A lot of users encounter that useful but some can't make sense of the error messages somewhere later in the tool chain. I can't and I won't rewrite every tool, but I can happily write in the header whatever the tools expect. I simply asking for a consensus for the things to write in the header. Discussing the usefulness of the current history model is a different question. As I got never an answer to an earlier post on that topic, http://lists.openstreetmap.org/pipermail/talk/2011-September/060027.html I assume that history is only a minor concern to most users. Cheers, Roland ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM XML declaration, JOSM, Osmosis et al.
On Wed, Sep 21, 2011 at 1:44 PM, Paul Norman wrote: >> -Original Message- >> From: Frederik Ramm [mailto:frede...@remote.org] >> >> Thinking about this, I like the stripping of the version number. >> >> We're having a lot of trouble with people doing mass edits by using XAPI >> etc. to download e.g. everything with name=McDonalds world-wide and >> replacing that with name=McDonald's - breaking a lot of correct things >> in the process. Not serving the version number on XAPI, Overpass and >> others would send a clear signal that these services are not to be used >> for editing. > > Like NE2's http://www.openstreetmap.org/browse/node/682273592? > > In spite of the problems with mass-edits based on XAPI queries, it is still > essential for some parts of my workflow. > > I used my local jxapi instance extensively fixing NHD tagging in California. > See http://lists.openstreetmap.org/pipermail/talk-us/2011-March/005438.html > for details. > > I have also used it for mapping highways in large areas, adding highway > relations and occasionally for normal mapping when I didn't want to hit API > limits. > > If jxapi ever stops serving data usable for editing then I will not pull the > latest code updates for my local copy. +1 I have my own xapi instance that I use for editing as well. It can indeed be risky and the type of edits you can perform is limited but there are some edits that would simply be impossible without the XAPI. Granted, most of the use cases are for cleaning up imported data which of course is an entirely different conversation... Toby ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM XML declaration, JOSM, Osmosis et al.
> -Original Message- > From: Frederik Ramm [mailto:frede...@remote.org] > > Thinking about this, I like the stripping of the version number. > > We're having a lot of trouble with people doing mass edits by using XAPI > etc. to download e.g. everything with name=McDonalds world-wide and > replacing that with name=McDonald's - breaking a lot of correct things > in the process. Not serving the version number on XAPI, Overpass and > others would send a clear signal that these services are not to be used > for editing. Like NE2's http://www.openstreetmap.org/browse/node/682273592? In spite of the problems with mass-edits based on XAPI queries, it is still essential for some parts of my workflow. I used my local jxapi instance extensively fixing NHD tagging in California. See http://lists.openstreetmap.org/pipermail/talk-us/2011-March/005438.html for details. I have also used it for mapping highways in large areas, adding highway relations and occasionally for normal mapping when I didn't want to hit API limits. If jxapi ever stops serving data usable for editing then I will not pull the latest code updates for my local copy. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM XML declaration, JOSM, Osmosis et al.
Serge Wroclawski wrote: > OSM objects are identified by three identifiers: > > Object Type, ID and Version > > Those three identifiers are necessary when talking about an OSM > object. Absence of one of them means the data isn't valid. The > type and ID are obvious, but the version number appears to be > tripping you up. The version number is not metadata, it's part > of the identifier of the object. No. "It can be", not "it is". It is absolutely a valid assumption for read-only purposes that, if the version number is absent, it refers to the most recent version at the time the extract was made. Version numbers are only required when writing back to the OSM database and that's a minority of OSM uses. cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/OSM-XML-declaration-JOSM-Osmosis-et-al-tp6814991p6816141.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM XML declaration, JOSM, Osmosis et al.
Hi, On 09/21/11 14:01, Serge Wroclawski wrote: Doing so also precludes merging results with any existing OSM database though. You can't have an extract then update via a service which strips version numbers. If you need versions in your extract. If your extract is supposed to contain only the latest version of anything anyway, then no point in even having version numbers locally! I think if you wanted to make this clear signal, you'd fake the IDs altogether, use incrementing ones starting at 0, for example. That would remove more information than necessary *and* be more complicated (due to having to keep intact referential integrity therefore having to keep track of assigned IDs). I think the sign would not have to be *that* clear. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM XML declaration, JOSM, Osmosis et al.
On Wed, Sep 21, 2011 at 7:18 AM, Frederik Ramm wrote: > Not serving the version number on XAPI, Overpass and others > would send a clear signal that these services are not to be used for > editing. Doing so also precludes merging results with any existing OSM database though. You can't have an extract then update via a service which strips version numbers. I think if you wanted to make this clear signal, you'd fake the IDs altogether, use incrementing ones starting at 0, for example. - Serge ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM XML declaration, JOSM, Osmosis et al.
Hi, On 09/21/11 13:13, Erik Johansson wrote: A bit off topic: I just tried overpass and was surprised that the default seems to be to strip the version and date, I'm not so keen on that "feature". Thinking about this, I like the stripping of the version number. We're having a lot of trouble with people doing mass edits by using XAPI etc. to download e.g. everything with name=McDonalds world-wide and replacing that with name=McDonald's - breaking a lot of correct things in the process. Not serving the version number on XAPI, Overpass and others would send a clear signal that these services are not to be used for editing. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM XML declaration, JOSM, Osmosis et al.
On Wed, Sep 21, 2011 at 8:12 AM, Roland Olbricht wrote: > JOSM and Osmosis both > complain about the absence of version attributes on the individual OSM > elements for data without meta data. > > Having OSM data with or without meta data is really a useful feature. The same > data with meta data is three times bigger than without, in a context, where > data size matters, and the meta data is usually only needed when one wants to > re-upload the data to the main database. A bit off topic: I just tried overpass and was surprised that the default seems to be to strip the version and date, I'm not so keen on that "feature". Is Overpass so geared for tools that don't care about uid/date/version/visible etc? ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM XML declaration, JOSM, Osmosis et al.
On Wed, Sep 21, 2011 at 2:12 AM, Roland Olbricht wrote: > Hello everybody, Hi. Please don't cross post. > If I deliver from Overpass API to JOSM the XML data with meta data and with a > plain tag, JOSM crashes with a NullPointerException on the first version > attribute. > > If I deliver, as suggested from a JOSM developer, with a > root tag, JOSM and Osmosis both > complain about the absence of version attributes on the individual OSM > elements for data without meta data. On the OSM objects you mean? As in the node, way and relations? > Having OSM data with or without meta data is really a useful feature. If you're speaking about individual OSM objects, that's not metadata; that's data. OSM objects are identified by three identifiers: Object Type, ID and Version Those three identifiers are necessary when talking about an OSM object. Absence of one of them means the data isn't valid. The type and ID are obvious, but the version number appears to be tripping you up. The version number is not metadata, it's part of the identifier of the object. Two objects may have the same type and ID, but only one can exist in the DB at a time, the one with the highest version. The version # is required on all transactions in the API. As for the osm tag, that's also not metadata. The version number determines what is valid osm data as per the .6 representation. Some things were allowed in .5 that weren't in .6, and when .7 comes out, I'm sure it will differ from .6. The parsers need to know what format the data is in. In this case, one might say the identifier for the xml type is: Name + Version > The same > data with meta data is three times bigger than without, in a context, where > data size matters, and the meta data is usually only needed when one wants to > re-upload the data to the main database. Firstly, if you're concerned about data size, don't store or transmit raw XML. Transmit XML with gzip. That alone should compress a lot. Second, use newer formats like pbf. They make the OSM data even smaller. > So what attributes would you, as a toolmaker, expect on the root tag for OSM > data with or without meta data? http://wiki.openstreetmap.org/wiki/OSM_XML The format is clear and none of the attributes are optional. - Serge ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
