OpenStreetMap

escada has commented on the following diary entries

Post When Comment
Will the DWG block us all one day? - Part II 20 days ago

Sorry, I missed the irony, but I know that some people have disputes with some members of the DWG regarding reverts and possibly blocks as well. Without further context it is hard to know whether you are doing this as a neutral observer or as someone taking sides with the blocked person.

Indeed, I'm not interested in who did the block, but in who was blocked and who(*) requested the block. I assume the DWG is not handling on their own, but that they are processing requests from the community to block people. So perhaps the people that block a lot just process more external requests than the others.

Some people in the above list only served the DWG for a short period (and are no longer part of it), so it is normal they placed less blocks than others.

I like the comment you gave to explain the spikes on the "Mean Block Duration", I'm missing that kind of additional information on the last two graphs, that's why they are "useless". They just give hard numbers without context, the numbers are not explained.

(*) not the actual person, but was it a group consensus, was it 1 person asking it, that kind of stuff.

Will the DWG block us all one day? - Part II 21 days ago

Since your last two graphs do not take into account the reason for blocking users, they are useless imho. Maybe woodpeck deals with mappers that destroy a lot of data or in a large area.

I see this as a blame game for the DWG, I think you should have focussed on the reason why people get blocked. But as you wrote "Just in case there are some troubles with the DWG (I am looking into it for a friend)", your investigation seems biased. If you would have revealed the reason why your friend in blocked (did she/he import from copyrighted sources, did she/he vandalise the work of others ?, did she/he add advertisements ?), I might have an idea why you are doing this research.

Will the DWG block us all one day? 27 days ago

Perhaps SEO-spam ? A SEO company can make a lot of different accounts, one for each business they want to "add". See e.g. this discussion on the Australian mailing list

Those people might not be interested in learning how one properly add a business with advertising.

AI With Satellite Images for OpenStreetMap 4 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 (https://forum.openstreetmap.org/viewtopic.php?pid=679826#p679826).

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 5 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 5 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 https://wiki.openstreetmap.org/wiki/Lanes. That is not option 2 I think.

Nominatim and Postcodes 5 months ago

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

Motorway Junction Node Placement 5 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 5 months ago

The German community discussed this topic last June: https://forum.openstreetmap.org/viewtopic.php?id=58116

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

My suggestion on OMS 6 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 7 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 7 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? 8 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? 8 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? 8 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? 8 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] http://overpass-turbo.eu/s/sjh (by the way all surveyed in case you wonder)

Craft mapping is the best method... 9 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? 9 months ago

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

Composite keys in OpenStreetMap: ref:highway, highway:ref or highway_ref? 9 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? 9 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 ?