Here’s another great question where ICU regular expressions come in handy:

https://help.openstreetmap.org/questions/57029/how-to-query-overpass-to-find-name-tags-with-chinese-characters

@ImreSamu :

and my problem with normal overpass “user” is that very hard to query the first v1:”user” of the object.

If the object currently still has object version 1, the query looks as follows:

way({{bbox}})(user:florinbadita_telenav)(if:version()==1); out geom meta;

(pending on the release of version() == 1, which is available for pre-release testing via http://overpass-turbo.eu/s/pLj)

Otherwise, if the object already has versions > 1, it’s indeed difficult to uncover the original creator. I described this issue here, but unfortunately, there’s no solution for it yet. Today, it would require so set the [date:...] to some value in the past and check the version for that particular point in time, which is not really convenient, especially if you look at a larger number of objects.

So, by checking the .osh.pbf file, you get direct access to all version 1 objects. That same information would be in Overpass API (back to September 2012). However, there’s no easy way to query for those object versions (for many different objects) as of today.

@Adityo: you can only check for a changeset number. It’s not possible to query by changeset metadata, such as some “#hotosm” tags. I don’t think this will change anytime soon. See https://github.com/drolbr/Overpass-API/issues/189

Hello friends of Overpass (btw: no camel casing in the name),

why can’t you check, if your ways with version 1 have been created in same changeset id as one of its nodes? If the way has been created as part of a split, its changeset id should be different from any of its nodes’ changeset id.

That should could probably be done quite easily via changeset() in an if: filter.

Also, I don’t quite get how the osmium filter on “v1” helps to solve the issue looking at the output above. Right now, the version filter used in the Overpass query does exactly the same already.

@RobJN: > Returning to the original issue (“Tickbox on sign-up page to accept push-notifications”), I’m not sure the PR solves this. I would prefer an option at new-user sign-up stage to select to subscribe to newsletters from the OSMF and from your local community. If you opt to get newsletters from your local community then you are agreeing to your email address being passed on to the Local Chapter that represents you region.

Unfortunately, the PR is not geared towards this. Primary target is allowing third parties to get your email address. Let’s take this oauth example:

http://osmlab.github.io/osm-auth/

With this PR in place you would get additional checkbox “see your e-mail”, if the third party requests it. Once approved, the demo app would also have access to your email (obviously this is not available on osm.org as of now).

For your new local community members, this would mean to manually send each new member such a link to a third party app to sign in (pretty much as it is today), and afterwards receive updates via push messages.

Bottom line: in terms of easy community management and keeping new members in the loop as you describe it, this PR may not be exactly what you’re looking for.

Push notifications is a dream for many of us.

It’s getting close. This PR would implement. May need some policy work. Showing support for the PR could help get this moving :) https://github.com/openstreetmap/openstreetmap-website/pull/1431

The current implementation as it stands really has privacy issues, as it would exhibit your personal email address if a third party requests it and you approve it. This won’t go away with some “policy work”.

I hope you realize that some people in the German forum found this really annoying and would immediately quit their OSM engagement! It breaks with a years long tradition of keeping the email address OSM internal, as mentioned in the privacy policy. For sure this will hit some people by surprise as they never expected something like this happen. If you’re a long term mailing list user, you might wonder, wtf? - still people are different and have different opinions and expectations on this topic.

Also, if you don’t authorize an App up-front, there will be no way to send a push notification at all. A user really needs to explicitly consent to it in the first place. Just randomly selecting some area and sending messages to all mappers will NOT work with this pull request on its own.

There are some ideas to mitigate the situation and have an approach that could work out for everyone without compromising privacy, and still offering the benefits of push notifications via email (or possibly some API). I’m not going to repeat that here, see the Github pull request for details.

Thanks for your time!

Have fun :)

Does this imply that an augmented diff may be updated after it has been published? Is there some mechanism to find out as a data consumer that there has been an update? I think for chsngeset analysis this is fine, I see some issues to keep a local db up to date with this approach. Would you agree to this?

Has it worked?

Well, it would be interesting to hear if you’ve got any feedback from new mappers? Did they find the welcoming message useful/interesting/helpful?

The message is not customised as from the beginning

I used to monitor my area for new mappers for some time, try to guess what they’re most interested in and sent them some customized hints. Certainly, that approach doesn’t scale at all, but it would be interesting to if such targeted hints would be more effective, or if it just doesn’t matter.

btw: the project’s name was changed to OpenStreetCam very recently : see https://lists.openstreetmap.org/pipermail/talk/2016-November/077058.html and osm.wiki/OpenStreetCam

Forgot to mention that there are already some QA tools out there reporting railway crossings without tag. As an example here’s a link to keep right! As the source is freely available you might take a look how their analysis looks like.

Another route for your data would have been Overpass querying for highways sharing a node with a railway.

That’s fairly easy to find out, actually: http://overpass-turbo.eu/s/jLw

Getting those missing intersections is a bit trickier: http://overpass-turbo.eu/s/jLx - showing railways in blue color and highways in red. There’s some glitch in the query I left as an exercise to the interested reader. Make sure to zoom in quite a bit, otherwise highways and railways cancel out each other in some cases.

I’m quite sure we should be able to do a single Overpass API query to get the pubs of London (as centroids for ways).

Since you asked: http://overpass-turbo.eu/s/gDj -> returns the same list in CSV format

Cheers

GPSBabel has some option to split GPX tracks based on distance/time, see online docs, option ‘sdistance’. Maybe worth a try to get rid of the noise.

Thanks for testing the Multiple user support for (user:…) and (uid:…) in your overpass turbo query. Hope you found it useful :)

Zu Zeiten als JOSM 59xx noch (un)freiwillig das genutzte OS im Changeset übertragen hat, haben die dt.sprachigen Mapper 3-4x soviele Edits (“num_changes”) mit Windows im Vergleich zu Linux gemacht. Mac hängt in der Tat etwas hinterher. Lässt sich mit 2-3 Zeilen Sql recht einfach ermitteln. Vielleicht ist da talk-de nicht (mehr) repräsentativ genug.

Why not use case insensitive search rather than listing all variations in the regular expression?

http://overpass-turbo.eu/s/dnw

Quicklink for the query above: http://overpass-turbo.eu/s/bGQ

Note: complete is not yet part of the official Overpass API and only included in the Overpass Lab Preview version at this time. An official release date is not known as of today. Read more about it. Please add comments/feedback to the GitHub ticket.

Hinweis: das complete Feature ist noch nicht Teil der offiziellen Overpass API, d.h. die genannte Query läuft in der Form nur auf der Overpass Lab Preview Version unter dev.overpass-api.de. Mehr Details dazu.

Thanks for an interesting Overpass use case.

Please note that the Overpass API dev instance you used to pull out your stats only dates back to March 2015 (unlike the official Overpass API instance, which has all the object versions back to September 2012).

This might skew your figures a bit: let’s assume a node has been created in Jan 2014 and last touched in Feb 2015. The dev instance would could recognize it for Feb 2015. as the Jan 2015 version is not known (it was no longer part of the March 2015 planet file I used to initially set up the database).

This restriction is documented on the following wiki page: link

As overpass can’t count tags (yet), it’s not possible to use overpass to get your original list of ids AFAICS.

That’s correct. At this time, there’s only a GitHub issue as feature request:

https://github.com/drolbr/Overpass-API/issues/197

Feel free to comment, if you like.