Re: [OSM-dev] Road Speed In South Africa Geotab
No one has replied, likely because it's not a really a dev@ subject, so I'll provide some basic info. On 9/13/2016 2:34 AM, Riaan Grobler wrote: *Problem* : We are experiencing more and more road that do not have updated road speed, see below as an example attached Road speed coverage will vary road class and region, and also if a mapper in the region really cares about mapping all the maxspeed data. I wouldn't expect it to be complete. The other problem is that once a update runs it over writes all the users information. That sounds like a technical problem with the process you're using to update. In general you want a process which will allow you to update your data without manual intervention. From the information here it sounds like you're making what's called a "derivative database" in the license, in which case it is licensed under the ODbL like OSM data is and you have to be able to provide that database to others. *Resolution* : I know you can make the changes on the site but I know you it needs to be validates first and this takes time. Is there a way to speed up the process if we supply you with all the details with pictures. There isn't a validation step between a user making changes and the data being available to everyone. OpenStreetMap is crowd-sourced project built around individuals mapping areas they know. Nor is permission required to map except in exceptional cases like imports and mechanical edits. If you have noticed a problem with our map data, for example a road is missing or your address, the best way to proceed is to join the OpenStreetMap community and add or repair the data yourself. The pictures aren't necessary for OpenStreetMap itself, but would be useful to both the OpenStreetView and Mapillary projects, both of which collect geotagged road photos. Is the above files the correct places to get the most up to date maps for South Africa ? The Geofabrik data extracts are provided as a service to the community by Geofabrik, a consulting and software firm specializing in OpenStreetMap. Their extracts are operated daily. It's possible to get more frequent updates directly from planet.openstreetmap.org, but significantly more work is required if you only want South Africa. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] user closing lots of notes / howto revert?
Is there a way to bulk-download or even better bulk-reopen the notes a user has closed? Recently a new user has closed 204 notes all over the place and without commenting and replying "fgdjfjdks" to mappers contacting him, so he was blocked by DWG. The wiki suggests http://wiki.openstreetmap.org/wiki/Notes#Viewing_notes_by_user this URL: www.openstreetmap.org/user/xyz/notes but this will split the results into pages of 10 (i.e. in this case 21 pages). Is there a way to raise this limit or maybe even download all of them in one go? Once you got the note IDs, which URL / API call will reopen it? Thank you, Martin ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] RFC: OSM data format MIME types
On Thu, Sep 15, 2016 at 08:49:24AM +0200, Colin Smale wrote: > Why the distinction for "historical"? The XML format is the same, isn't > it? The "normal" version just limits itself to a single (the most > recent) version - it a simple subset of "historical". There is one difference, the "visible" attribute is usually only available in history files. But the more important reason in my opinion is the use of those files is different. A program that can read one type of file might not necessarily cope with the other. And if it can, it might do different things based on which type of file it is. I have been running into this problem developing Osmium, that a program can't "just do the right thing" if it doesn't know whether an input file is a normal data file or a history file. (And there is no way to find out until you find the first objects with multiple versions in there (which is not trivial to find out if files are not sorted (which they don't have to be.))) Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] RFC: OSM data format MIME types
On Wed, Sep 14, 2016 at 08:55:16PM -0700, Paul Norman wrote: > I'm planning on registering MIME types for OSM formats in the vendor tree > and could use feedback. If you're unfamiliar with registering MIME types, > https://github.com/mapbox/vector-tile-spec/issues/48 is a reasonable > overview for a registration that took place with a different format. > > > The obvious type for OSM XML is application/vnd.osm+xml, but there are a few > unanswered questions Why not application/vns.openstreetmap... ? Longer, but much easier to understand and search for. > - Is .osc a different type? I'm think yes. Tools that parse one don't > normally accept the other in its place, they normally have different file > suffixes, and the top-level XML elements are different. > > - Is osc returned from the server a different type from what is uploaded? > I'm inclined towards no. This is more a matter of selection of valid > identifiers. > > - Where does history fit in > > I'm inclined towards > > - application/vnd.osm+xml for OSM XML > > - application/vnd.osm.osc+xml for OsmChange XML > > - application/vnd.osm.osh+xml for historical XML > > - application/vnd.osm.osmpbf for current data PBFs. pbf is not a MIME > suffix. > > - application/vnd.osm.oshpbf for historical PBFs. > > - application/vnd.osm.o5m > > - application/vnd.osm.o5c These all more or less are the file suffixes used. How about something like application/vnd.openstreetmap.data+xml application/vnd.openstreetmap.data.pbf application/vnd.openstreetmap.history.pbf application/vnd.openstreetmap.changes+xml Not sure myself. The naming and file formats are a mess as they are. :-( > I'm not sure where to slot changeset data into this. Changeset data can be > present in an OSM XML file alongside other data (e.g. with planet dumps) or > standalone. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] RFC: OSM data format MIME types
Hi! On Thu, Sep 15, 2016 at 5:55 AM, Paul Norman wrote: > I'm planning on registering MIME types for OSM formats in the vendor tree > and could use feedback. When we aim for standardization, we could also give the XML scheme for OSM XML [1] some love and release it as the one OSM XML scheme. With the rising number of applications writing OSM XML interoperability issues arise. Often it is unclear which of both application omits required fields/attributes and/or takes optional files/attributes for granted. Cheers, Simon [1] https://wiki.openstreetmap.org/wiki/OSM_XML/XSD ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] OSM API lookups to complement minutely diffs?
I'm setting up a Kafka publish-subscribe messaging system delivering minutely diffs. AFAIK augmented diffs are rather an experimental feature and I'd like to avoid the latency time and blackouts of overpass which runs in same server. So I'm concentrating on the main OSM API. Now, osmChange XML like http://www.osm.org/api/0.6/changeset/42143238/download obviously does not include all info (e.g. tags) from ref nodes/ways/relations. I'm not looking for specific info but I'd like to get at least all data about nodes/ways/relations which are created/modified/deleted in a changeset. Is it OK to do API lookups like this https://www.osm.org/api/0.6/nodes?nodes=59906080,4400821613 even for minutely diffs? Any alternatives? :Stefan ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM API lookups to complement minutely diffs?
On Thu, Sep 15, 2016 at 4:53 PM, Stefan Keller wrote: > I'm setting up a Kafka publish-subscribe messaging system delivering > minutely diffs. > > AFAIK augmented diffs are rather an experimental feature and I'd like > to avoid the latency time and blackouts of overpass which runs in same > server. So I'm concentrating on the main OSM API. > I've also experimented with this sort of thing and ran into similar hiccups as you. Also, if you want to further reduce latency don't forget about the streaming replication service: http://wiki.openstreetmap.org/wiki/Osmosis/Replication#Streaming_Replication_Wire_Protocol Last I checked it wasn't running, and I think TomH would be hard pressed to get it to work again, but if you end up building something that would be useful for a wide array of people it might be worth revisiting that. > Now, osmChange XML like > http://www.osm.org/api/0.6/changeset/42143238/download obviously does > not include all info (e.g. tags) from ref nodes/ways/relations. > > I'm not looking for specific info but I'd like to get at least all > data about nodes/ways/relations which are created/modified/deleted in > a changeset. > > Is it OK to do API lookups like this > https://www.osm.org/api/0.6/nodes?nodes=59906080,4400821613 even for > minutely diffs? Any alternatives? This is where I stopped working on this idea. I ended up making *lots* of requests to the API server to fill in missing data and I didn't think it would be very nice to my fellow mappers if I scaled that up and made it run 24/7. At this point I started experimenting with ways of maintaining a full history database to help make these sorts of lookups more performant, but then ran out of time to work on this project. I think a more interesting path forward for this kind of problem is to resurrect the aforementioned streaming replication protocol and modify it to include changeset and "augmented diff"-style information. My intuition says that making smart SQL queries against a read replica database rather than adding API load might be more efficient and useful for lots of consumers. I'm happy to be proven wrong, though. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM API lookups to complement minutely diffs?
Hi, On 09/15/2016 10:53 PM, Stefan Keller wrote: > AFAIK augmented diffs are rather an experimental feature and I'd like > to avoid the latency time and blackouts of overpass which runs in same > server. So I'm concentrating on the main OSM API. This reads to me like: "There is a third-party service that solves the problem I have, but because it is experimental, I would like to build my own experimental third-party service instead" ;) The augmented diffs were made to solve exactly the problem you have. The underlying idea that Overpass implements - load updates from OSM into its own full history database and generate augmented diffs using that database - is by far the best solution in terms of load caused on the central servers. It also scales nicely; if a thousand people decide to run Overpass instances to produce their own augmented diffs then the API won't suffer. If you cannot work with overpass but must implement your own version of that, then you should at least copy the principle. The central OSM API is meant to support editing activity and doesn't scale to support use cases like yours (especially if others come after you and decide they need their own system because yours is experimental ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM API lookups to complement minutely diffs?
On 9/15/2016 1:53 PM, Stefan Keller wrote: Is it OK to do API lookups like this https://www.osm.org/api/0.6/nodes?nodes=59906080,4400821613 even for minutely diffs? Any alternatives? No, particularly if your code takes off and multiple people start running it. I would guess that it would hit rate limits and be automatically blocked. If all you need is node positions this can be done fairly efficiently for the entire planet with something like osm2pgsql flat-nodes. If you need full information this takes more space. But you should consider if you're just rebuilding augmented diffs. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
