escada has commented on the following diary entries

Post When Comment
AI With Satellite Images for OpenStreetMap 2 months ago

Do you know about the problems of the current state of the AI applied by Facebook where many line-like features were recognized as road (

I think armchair mapping is still giving better result at this moment.

So probably in the future AI can be better than humans, but we are not there yet.

Motorway Junction Node Placement 3 months ago

@andy mackey: In a coordinated effort a couple of years ago (started in Germany, although I had already mapped tens of exits in Belgium before), people started mapping turn:lanes. This included exit lanes. AFAIK, in Belgium, The Netherlands, Germany (and possible other countries), people opted for 1 or 3 or Paul Johnson's style (not a huge difference between the 3). Never 2. A "lane is not a separate way".

So I hope that everybody who thinks 2 is better because it is more appealing, or better for navigation (which it is not -- see my comment above), will appreciate the above effort and will keep a consistent way of mapping by not using option 2.

Motorway Junction Node Placement 3 months ago

@Andy Allen: to be honest, I've never heard that from OsmAnd, nor MagicEarth. One can also add placement=transition on that short segment. (which is perhaps ignored by all satnav apps)

People have been mapping those things based on That is not option 2 I think.

Nominatim and Postcodes 3 months ago

Read with great interest and bookmarked for future reference. Thanks for your hard work on Nominatim

Motorway Junction Node Placement 3 months ago

AFAIK the German community never placed the junction at the beginning of the lane, at least when people followed the instructions given for the week-assignment on turn:lanes 2 years ago. The Belgian and Dutch community followed the same rules. I assume the other neighbouring countries did the same.

So the option proposed by Omnific is not how it is done in a certain part of the community.

The difference between theoretical gore and physical gore is harder to see. I guess the junction is typically placed somewhere between those 2 extremes.

When I compare the instructions of e.g. OsmAnd or Magic Earth with the distance signs to the exit or the spoken instructions given by non-OSM navigation systems, the place seems to match. Hard to tell given the precision of a GPS while you drive around 90km/h

As imagico said, please take a look how the exits are mapped. Are there differences between the different countries ? I think that you should be better informed about how things are done around the world before enforcing your rules upon the rest of the community. Before making a decision I would love to see numbers per country.

I hope you will stop the process of mapping to your rules until there is more clarity.

On Sett Pavements 3 months ago

The German community discussed this topic last June:

I have to re-read the thread to remember whether there was any consensus.

My suggestion on OMS 4 months ago

OpenStreetMap is about the data to create maps, not about applications. I firmly believe we should focus on data (and perhaps tools to map and to verify the data), but should stay away from apps for end users. There are so many applications of maps, and as Mariàn wrote, there are already plenty of apps out there using OSM data.

There is no reason to compete with those app developers.

Proposal - OSMF Should Adopt a Code of Conduct 5 months ago

I wonder how such a CoC would work on e.g. a Telegram group with the name "OpenStreetMap". How can you enforce a CoC on a platform that is not under control of the OSMF, but is clearly related to the OSM community ?

Do you see this as a problem ?

Editing in OSMAnd 5 months ago

Main drawbacks of OsmAnd for editing for me are:

  • you can only add point features
  • as I do not have an subscription for hourly updates, the map can be outdated (up to a month), so in the meantime someone could have added the same POI, especially in areas with several mappers.
Why is Nakaner not in favour of your proposal? 6 months ago

@cm8: please tell me why "diameter" is better than "fire_hydrant:diameter". I have not heard a single argument that convinces me. What is the quirk, misnomer or bad use of namespace in this case? Is it really a fix or improvement ? Why do we need it to be called diameter ? Why is it better for a mapper to use one over the other.

Why do I have to learn a new mapping scheme ? Is that taking care of mappers ?

Why is Nakaner not in favour of your proposal? 6 months ago

@Viking81, as Nakaner wrote, it is not only the hundreds of mappers that have to go through the pain of remapping there stuff, it is also all data consumers that have to add code to use "pressure" besides "fire_hydrant:pressure". This means creating issue cases, planning, them, developing them, testing them, releasing them and maintaining them without any improvement for the end consumer. This is something each development team hates (I know, I do software development).

You want to change fire_hydrant:pressure to pressure and look for 10 other mappers that agree (and hopefully no one objects). There is no guarantee at all that there won't be a group of 10 other mappers that will do the opposite within a couple of months or years. Just renaming tags is such a waste of time & resources.

I wish OSM had something similar to Wikidata. Wikidata abstracts the tags away. The have P. Then you can name & describe it however you want, you can add synonyms, translations without any problem. For the all data consumers it remains the same P

I think people assign too much value to how a tag is written. For me there is no difference between pressure and fire_hydrant:pressure. It's the same. I would happily use one or the other, but there is no reason to replace one with the other.

Another drawback is that you just make the database bigger with another version that is just replacing a tag with a synonym. Whoever is using a template in an editor will hardly notice what the actual tag is, so why would they find "pressure" better ?

BTW, I didn't vote, because the voting process is no longer working. There are too many different opinions that do not participate in the discussion, and only vote. Or the voting group is not represenative for the community as a whole. I don't have a solution for those problems. I just vote by using tags (or using the tags my editor gives me).

Why is Nakaner not in favour of your proposal? 6 months ago

p.s. Luckily the proposer of the new fire hydrant tagging scheme mapped 1095 hydrants so far. At least s/he would feel to remapping pain as well :-/

Why is Nakaner not in favour of your proposal? 6 months ago

@Warin61, do you seriously want me to spend time to retag all 1978 fire hydrants I mapped [1] in the past, just because 10 mappers decide that fire_hydrant:diameter is not hip anymore and has to be replaced with diameter ? Do you think I have nothing better to do ? I would rather map another 1978 fire hydrants, than retag the ones I mapped. I noticed you mapped 6 fire hydrants in Sydney, that is a totally different scale

Of course I could use Overpass + Level0 to do the retagging in a few minutes, but still it is a waste of time IMHO.

So I totally agree with Nakaner's "Avoid changing heavily used tags".

[1] (by the way all surveyed in case you wonder)

Craft mapping is the best method... 7 months ago

I was not directly referring to lack of detail, just to adding wrong data.

But in my region (Flanders, Northern part of Belgium) there is 1 mapper that did almost all landuse based on aerial imagery. Due all kind of circumstances, a lot of the landuse get mistagged. He can do much more from his chair, than we can check on the ground. I rather have no landuse than a brownfield in the middle of a nature reserve of a vinyard in a totally impossible place.

So yes, armchair mappers can add more incorrect data than "craftmappers" can correct on short term. We also do not have the time to comment on their work in the hope they learn to better interprete imagery, as they moved on to the next topic before we get there. A craftmapper will still be around and will learn for her/his next project.

That's my problem with "speed with which armchair mappers map" vs. craftmapper.

Composite keys in OpenStreetMap: ref:highway, highway:ref or highway_ref? 7 months ago

problems with markdown. sorry. wikipedia: should be wikipedia:language.

Composite keys in OpenStreetMap: ref:highway, highway:ref or highway_ref? 7 months ago

"due to the wikipedia: syntax" should be "due to the wikipedia: syntax"

Composite keys in OpenStreetMap: ref:highway, highway:ref or highway_ref? 7 months ago

Does that fact that wikipedia: exists has any impact on your reasoning ? Is there a potential problem where the wikipedia:brand can be considered as the Wikipedia article in the "brand" language ? I think you cannot use wikipedia: due to the wikipedia: syntax. What is your opinion ?

Craft mapping is the best method... 7 months ago

I would say that "speed" is the enemy of a good map. Everything that is done too fast leads to a bad map. This means that any method that supports rapid mapping will more easily lead to a bad map. Imports that are done to fast, tracing of aerial imagery that is done too fast, local mapping that is done to fast.

But while it is easy to quickly do an import or trace something, it is much harder to quickly do local mapping.

Any method is fine, if it is done carefully and where high quality is the goal. The goal should not be having more data sooner. That leads to bad quality.

Add this place please 7 months ago

We cannot use Google as a source to map something.

If you are local, you can add the place yourself. It's not that difficult. Just create an account on, start the iD editor, follow the tutorial and start editing.

Happy mapping

Just uploaded my first track 8 months ago

Hello Light Lee,

welcome to OSM. Be warned, it can be very addictive :)

No you cannot add additional information to the GPS trace. You can in any editor show your trace (even without uploading it to OSM) and retrace with the drawing tools offered by the editor. After tracing you can start adding the type of path/road and the surface characteristics.

The GPS trace is never automatically converted to an OSM way. The reason: in general a GPS trace contains a lot of errors, depending on the accuracy of the device. This is on its turn affected by the place you are travelling. Much worse near tall buildings or under trees.

Warin61 already pointed out a good guide and the iD editor comes with a build in tutorial.

Have fun mapping your trail