OpenStreetMap

mvexel has commented on the following diary entries

Post When Comment
Watching the Watchlist about 17 hours ago

jgpacker - wow, I never knew that was possible! Thanks.

Complex Intersections, or Why We Should Get Rid Of exit_to 2 days ago

I also added a comment to the Discussion section of the highway=motorway_junction page, where exit_to is still referenced in a few places. I want to move to de-emphasize exit_to in preparation for a plan to deprecate this tag altogether, if the community feels this is the right thing to do.

Complex Intersections, or Why We Should Get Rid Of exit_to 3 days ago

I edited the exit_to wiki page to reflect that usage of this tag is being discussed here.

Complex Intersections, or Why We Should Get Rid Of exit_to 3 days ago

imagic: In the case I highlighted in the blog post, there is a destination further down the route (I-95 North / South) that the beltway connects to. You could compare it to control cities There is no way to derive that information from the data. This is why I was looking at specifying that as destination:ref:to as a suggestion, but in general I am not in favor of many levels of colons in the tags.

Re: the blurred signs, this is an unintended side effect of the anonymization image processing, I assume. I have just raised it with them.

Russ: The documentation issue is only one of the problems with exit_to, but it shows that nobody has cared enough about this tag to properly document it so far. It likely has contributed to inconsistent usage. I don't know. I haven't found any inconsistent use of exit_to myself, and my issues with the tag are not that it is used inconsistently.

Which camera for capturing 'Street View'? 4 days ago

Thank you for your contributions! Drift and Contour seem like great candidates. I opted for the GoPro because of the form factor and accessories available, and the reportedly good image quality.

When I got it, I turned off sharpening, auto-white-balancing, and other pre-processing I could find to get the purest possible reading from the sensor. Here is a result from a test shoot. This is - obviously - taken with the camera mounted inside the cabin. I am getting a suction mount (and some fishing line as backup :) so I can mount the camera on the hood instead.

Here is detail at 100%:

detail

I don't think this is all that impressive. Perhaps it's the image compression. Perhaps I need to tweak the settings a little more.

The post-processing was a little more tedious than I had hoped. I recorded a GPS track using my Garmin Dakota 20. This delivers a standard GPX format track. My first thought was to use the JOSM geotagging plugin to write the location information to the images. This works great, but it does not write the GPSImgDirection tag, which is required by Mapillary. (This should not strictly be necessary, as they can calculate the direction based on the GPS track, given user input of the relative heading of the camera to the driving direction. I am talking to them to get that resolved.)

The tool I settled on for now is a pretty smart Ruby script called gpx2exif. It does calculate and write the GPX location and heading, so the images are ready for upload to Mapillary straight after processing them through this tool. I still use the JOSM plugin to determine the offset between GPS time and camera time.

The main issue with gpx2exif is that it wraps the great but excruciatingly slow exiftool. Processing a few thousand images - which is a pretty typical use case - takes hours. This could be improved a lot if they would switch to exiv2. I filed a ticket with them and got a prompt response from one of the maintainers, Craig Taverner - who incidentally also wrote a great blog post about this very process. I also looked at doing it myself but my limited Ruby skills and the lack of a decent exiv2 ruby wrapper made me give up for now.

Then, when I finally had my first sequence ready for uploading, Mapillary's web uploader did not like my 700+ image sequence very much - at least not on Firefox. After a lengthy wait and a lot of 'Unresponsive Script' alerts I finally decided to force quit the browser, but it seems that the process had magically completed in the background.

So, to make a long comment short, it all works, but I need to play with the image preprocessing and quality dials in the camera, it takes forever, and it would be cool if Mapillary would just let me upload GPS + image sequence in a robust web uploading environment. Or better still, offer a bulk upload API that developers could go to town with.

Complex Intersections, or Why We Should Get Rid Of exit_to 6 days ago

Here's a situation I would like some advice on:

photo

(If it is too small to see, here is the full size image.

The left two lanes are a continuation of I-80 Eastbound. The right two lanes are the start of I-215 Southbound. Neither are _links. Currently, the only relevant tag is on the junction node: ref=128 indicating the exit number.

Here's how I would tag this with destination:

  • The way branching left would get destination=Cheyenne
  • The way branching right would get destination=Belt Route.
  • Both ways already have ref tags indicating the freeway number.

Because neither branches are _link ways, the ref on the ways, or the relationship membership, should be sufficient to infer the full signposting, right? If either or both were _links, would they require a destination:ref?

Also, destination=Belt Route is a little strange intuitively, but it is what is on the sign, so that is what would end up in the tag, correct?

(I am disregarding the more sophisticated variant of using destination:lanes as described on the Lanes page, an example can be found here).

Complex Intersections, or Why We Should Get Rid Of exit_to 6 days ago

@RussNelson - I tried to describe the problems with exit_to that are solved by destination in the post. Let me summarize and add some insights shared in previous comments. destination is a more generic solution for signpost information - as Maarssen Mapper pointed out, destination can also be used on non-link ways to indicate control cities; it allows for a clear separation of named and ref parts of the destination; it can be combined with :lanes to add lane level granularity; and finally, it is better documented and has wider support globally.

For 'simple' motorway exits, the transition could be as simple as copying what is now on the exit_to tag to a new destination tag on the exit _link. There may be an opportunity for a mechanical edit, but that would require additional discussion.

For more complex situations, the tagging needs to be reviewed manually, and ideally, destination tags should be added on the main motorway ways (and perhaps trunk as well) to indicate the control cities.

Complex Intersections, or Why We Should Get Rid Of exit_to 9 days ago

Thank you everyone for adding your insights and opinions to this article. It's a day off here and a particularly nice one here in Utah, so I intend to spend the rest of it playing outside, but I will come back and respond over the weekend!

FWIW, for Scout we currently only support exit_to mainly because it has the most extensive coverage in the market it serves (the US). We are currently embarking on an effort to add more signpost information to the U.S. interstate systems, and I want to make sure that we adhere to the best possible tagging convention. If that turns out to be destination= we are quite happy to (help) make that transition, both in the app and in the data.

The Missing Mappers Problem? 10 days ago

Thanks for sharing these insights!

New MapRoulette Challenge: Crossing Ways 12 days ago

AndiG88 - correct. I still want to get closer collaboration with KeepRight, and have been in touch with the author before, but due to a lack of time on my part, I haven't been able to follow up.

New MapRoulette Challenge: Crossing Ways 12 days ago

Pieren: You have discovered a bug. bridge=viaduct was not processed and will appear as false positives. We are working on a fix! This is less than 1% of bridges in the US, most are just bridge=yes. We discovered another bug where we did not recognize _link ways that are also tagged as bridge (or tunnel). This is also being fixed.

Thanks for reporting!

New MapRoulette Challenge: Crossing Ways 13 days ago

Thanks @Alan, fixing...

New MapRoulette Challenge: Crossing Ways 13 days ago

jumbanho - those are excluded for now, but it's a good idea for a followup challenge.

Extracting Data from OpenStreetMap History Files Using the *New* Osmium about 2 months ago

Thanks for this write-up - Osmium and the tools that use it can be a little tough to get into, and articles like these help.

I have used osmjs, the Javascript v8 interface to Osmium, for a few projects that may be of interest to you - see this diary entry for a discussion.

New MapRoulette Challenge: Ways Needing Smoothing 2 months ago

Sorry for the intermittent problems, folks! I hope everything works well again now.

We actually added a new feature, more about that in a new diary entry soon. It's already live on MapRoulette.org - can you find it? :)

OpenStreetBugs Phase out: Done 2 months ago

Fantastic job, Werner. Thank you for taking on this big effort of closing out all these 'forgotten' OSB's.

New MapRoulette Challenge: Ways Needing Smoothing 3 months ago

Katie: there's no strict rules! As many as you think makes it look decent. Be sure however that you are zoomed in far enough to really see the road well on the aerial image. (You should be able to see the markings on the road, and cars, if there are any.) I would also suggest that that it's not necessary to put any additional nodes on straight parts of the way, as those do not add any useful information.

Another new MapRoulette challenge: Suspected Missing / Wrong One Way Streets 3 months ago

Chris: That is a very good point, and I should (and will!) include a note of caution to MapRoulette users. I am sorry I messed up data in your area, and thanks for watching over it.

robbieonsea: These are Telenav traces only - so yes, these are driving traces, not walking or cycling.

The confidence level is a simple ratio of traces going in one direction versus traces going in the other, and for the results that are in this particular MapRoulette challenge, we set the threshold at 95%, meaning that for a way to be flagged we will see at least 95 out of 100 traces going in one direction for that segment. There is also a minimum threshold for the number of traces we want to see, but I cannot recall what that threshold is.

Incidentally, what you see right now is the first batch of 5000 tasks out of a total of over a hundred thousand, and I will load them sorted by the number of traces. So the tasks you are seeing in MapRoulette today are the ones that have the most traces attached to them.

Ideally, as Mappo also mentioned, this challenge would be fed to tools that allow for on site verification. Osmose is a good candidate, especially now that Frederic is doing a ton of work to make that tool mobile-friendly. I have been working with Frederic over the SOTM US weekend to build a bridge between Osmose and MapRoulette, so we will see an exchange of tasks / challenges between these two QA tools in the near future.

Thanks everyone for the feedback!

This is the first day of my OPENSTREETMAP! 3 months ago

Welcome to OpenStreetMap! If you want some help with your first steps, LearnOSM can be helpful - unfortunately not in Chinese (yet). http://learnosm.org/en/beginner/

Or just ask here, or on the live chat at irc.osm.org - happy mapping!

New MapRoulette Challenge: Ways Needing Smoothing 3 months ago

hobbesvboyle: The tasks need only one person to say it's fixed (or not an error) for them not to appear again. The reason you are seeing what seems to be the same task twice is that the logic that detects these sharp angles sometimes operates on parts of ways, so one way that has multiple sharp angles may appear twice. Also, folks often choose to load a bigger area once they fixed the error, as it's often obvious that there's more things to be fixed. In the process, they may be fixing what are separate tasks in MapRoulette :)

Stalfur: I am writing up a challenge creation guide. I will post a diary entry when that is done.