d1g has commented on the following diary entries

Post When Comment
A Rant: The Way Beyond Craftmapping That Nobody Is Talking About 22 days ago

No the term "Craft" is fine. That's why the term is co-opted and worn proudly as a T-shirt. The offensive bit was saying that people who map their own neighbourhood (hello? central idea of the project!)

Maybe I think core idea is about getting 3D scanners and copters cheaper and legal, so we don't have to go outside.

Maybe all or most of the tagging will done using AI.

Maybe we should have tags at wiki to be translated in 200 languages.

Promote well tested and productive/good idea - fine. Call yourself ordinalist/elitist because you are using good ideas - eh?.. OSM is not about this, use real social network if you really into it.

The "Armchair Mapping" wiki page which d1g so politely refers to, is an example of my own attempt to flush out the topics.

It was fine as draft/your opinion, until somebody decided to make guideline out of it.

"Armchair mapping" was never widely discussed in Russian community but it was used by some as derogatory term here or there. Like it or not, "Armchair mapping" was used to abuse others and their methods and not to show what can be used in OSM

"possible sources" can be used instead but you won't be famous if Wikipedia won't mention you as "coiner" of the two-word term. Hmm...

We don't need to invent new derogatory words in English. We don't need more derogatory terms in OSM.

I don't think that creating a neologism in English language (a very ambitious move, indeed) would help us to describe what do WE have in OSM.

In OSM, WE have very few things to say about Geodesy, Engineering and other related fields who use Geodesy results only as intermediate data. 1cm is top-notch in Geodesy and bottom end in Metrology.

Sometimes you shouldn't write an "Armchair mapping" article in your life.

"Armchair mapping" can be replaced with:

  • You haven't seen one, don't claim for it (Bing/knowledge/local knowledge/survey); don't copy other maps and not accepted sources
  • Even if you seen one, It was long time ago, forget it; don't fight others who seen it just recently,
  • Respect others who have more recent sources or more accurate results

and read it a bit more carefully than d1g did

You should work on your writing habits Harry and thank you for calling me a "patient reader" after I revised every single edit to Armchair mapping page but also all Internet results with this topic in two languages. For example, current page covers "current and local knowledge curated by many communities" way better and uses 10-50 times less words. Think about it next time.

Now when we have debates over techniques and "Craftmapping" (in 2016), we should state:


For example; when we have automatic imagery classifiers/annotators, 80-90% verifiable data:

  • can be adapted by active community (interest + competence + free time)
  • it may kill interest of few mappers who just started work in their metro. Please wait with imports when "they are ready to fill otherwise empty spots" or "they agree to have % of errors in some dataset and work on it"
A Rant: The Way Beyond Craftmapping That Nobody Is Talking About 24 days ago

Nobody is talking about "craft mapping" or "armchair mapping" because these words are meaningless. But more, they are stupid and aggressive:

  1. place source=* tag on your changeset
  2. please mention if your data sources are very old (years old or more); tell "survey" / "local knowledge" otherwise
  3. don't b*ch about sources of other users like Harry Wood -, don't b*ch at your blog
Trolltags about 1 month ago

abandoned=yes is deprecated for 5 years already.


It is not OK to use one tag (for example amenity=hotel) and add second tag that negates or massively change its meaning

Please stop "opening eyes" in 09-2015 about "trolltags" on what was settled in 2011/12?!

History of all Tags about 1 month ago

... but wait, if you search more, "payment:troika" is used in OsmAnd already

and was discussed in some more minor discussions at other channels

History of all Tags about 1 month ago

For example, "payment:troika" was discussed deep in the public trasport thread

There no discussions of it at tagging list or at wiki or anywhere else in OSM.

History of all Tags about 1 month ago

tyr, I had idea to include Google results with "amenity=public_building" query


Full timeline:

2006-03-24 wiki: amenity=public_building added to map features

2007-10-16 JOSM: amenity=public_building added


2015-11-15 JOSM: office=administrative, office=government added

2016-03-02 wiki: office=administrative and amenity=public_building deprecated

2016-04-01 JOSM: amenity=public_building dropped and deprecation warning added

should be drawn as vertical lines with number. Where every number is linked to external resource to see if there any mistakes during discussion.

We (or Math1985) shouldn't fiddle with wiki or any other resource to see when tag was added/removed/mentioned for the first time.

We definitely need such tool.

Visualizing's Map Views about 1 month ago

Thank you tyr!

trolleway published report using NextGIS platform some time ago, but python/PostGIS scripts are available for anyone to use:

cornet tails

I don't think that "cornet tails" contributed by legitimate OSM users.

I haven't seen an osm service that uses smooth transition on tiles...

If user agent is is not Google Earth then I'd rather investigate logs more seriously around such regions but with user agents times and ips.

Почему natural=heath - это не что угодно 2 months ago

Третье моё сообщение как раз не про landcover=*, это про любые геометрии с тегом викидаты или википедии т.к. Amazon rainforest единственный во всём мире. а тегов для экосистем пока нет (или есть?)

Указание миллиона landcover=* прямо противоположено указанию одной (1!) экосистемы.

Отличия у "экосистем" и landcover=* есть (как и множество корреляций), поэтому я про landcover=* вообще не упомянул.

Почему natural=heath - это не что угодно 2 months ago

Лично мне до лампочки что в Амазонке "Влажные тропические леса". Я деревья и по Bing вижу, но рисовать не стану грубые контуры без осмотра местности.

Там деревья. natural=wood, а не natural=special_case_of_the_tropical_rainforest_only_seen_in_Amazonka

Ту же экосистему

5,500,000 km2

Можно хоть тысячами километров обозначать, хоть самыми грубыми геометриями:

Каждый кусочек леса-то зачем заставлять всех обозначать и выучивать это в вики?

Почему natural=heath - это не что угодно 2 months ago

Грубо говоря начинаем с трех тегов tree_row, tree, wood, а уж потом переходим к обозначению "экосистем" лесов - уже отдельным тегом.

Здесь и отсеиваются тем кому абсолютно до лампочки экосистемы и те кто разбирается в кислотности болот и степей не должен каждую деталь объяснять.

grassland=* тег практически не используется (экосистемы), все пользователи отмечают траву natural=grassland

Травы не закончились, другие объекты не закончились, а экосистемы grassland=* не в приоритете обозначения.

Но, конечно, можно настаивать что natural=grassland - только "степи". Как-то так.

Почему natural=heath - это не что угодно 2 months ago

Даже если разбор BushmanK был без ошибок, у меня есть одно замечение которое нельзя игнорировать.

Экосистемы должны быть тегом отличным от natural=, полагаться на "экосистемы" в natural= - наивно

Это должен быть и natural=* тег и тег экосистемы.

В natural=* нужно оставлять простые и понятные объекты "воды", "деревья" и прочие. Вклинивать сюда (natural=*) экосистемы (которые требуют не нулевых знаний и подготовки) это как расставлять грабли всем пользователям которые хотят отмечать простые объекты вроде "лесов", "трав" и прочих.

Уважаемый BushmanK, я понимаю что старое значение natural=grassland было как бы "степь" (экосистема), но пользователям всё равно, они отмечают траву. Большие опусы на обсуждениях вики страниц здесь не помогут. Нужно дополнять действия пользователей и предлагать альтернативы.

И именно поэтому (из-за пользователей, а не самых точных определений) я наконец-то предложил обобщить natural=wood и natural=grassland до определений без намёка на "экосистемы" и без "дикие".

Osmlint to detect errors in OSM 7 months ago

Yes, thank you for examples in repo!

It is easier to learn new tools when you can compare apples from one tool to apples in other tool (and especially if it was done before).

Welcome to the new Missing Maps 8 months ago

A person that checks edits

AFAIK, HOT team have a person that checks how a task was performed with possibility to redo a task by other person.

I don't think we have a dedicated person in OSM that checks say Carnildo edits if they were valid or not and asks other person to implement same data.

At limited scale MM and HOT may perform well (something in data > nothing in data). But of course we don't want feed random data in OSM (but there nothing specific about Missing Maps).

Checker role shouldn't be permanent.

You could use statistics

Take 10 contributors, pay a banana per building. Tell them: you will get a reward ONLY if you draw a true building.

If one draws 10% less or more buildings than others in the group, he gets no reward.

IRL there would be "backroom deals" but with randomized nicknames and Internet you can get 10 persons that never knew each other.

This is exactly how captcha-driven data collection works.

Good thing about it is it scales even more with more contributors.

I never seen an implementation of this in OSM.

Osmlint to detect errors in OSM 8 months ago

Lovely dashboard! "Filter data" is a gem, but unexplained/no docs.

I would recommend to explain how to write and process amenity=cafe+name=Cafe Mirage -> amenity=cafe+Mirage using OSMLint - so users are not afraid of new interfaces and workflows (because common tasks are the same).

Could you please create sample code how to detect disconnected graphs (connected components with less 20 ways)? It is possible?

More platform independent code would be nice in examples (Java / Python)

Removed 8 months ago

Meersbrook, please explain concerns about your locality or what "common mistakes" you see. So if they are true, you simply can point to them next time somebody have to make hard decisions in unknown territory for them.


  1. don't detail territory A because it was changed recently
  2. please help me with common highway graph mistakes
  3. there no road, bridge was broken 2 years ago
  4. please don't trace highways in territory B because ...

In the end, they are just editors of OSM, but with less knowledge of territory than you.

Use note=* tags in data, so nobody have to guess how poor or outdated imagery is. Use your native language if you feel slow in English.

Use more descriptive comments in changesets about important objects. Your commenting style "Features around (territory)" can be deduced from bbox of your changeset.

If a changeset should contain link to your guide, then post link in changeset comments!

Have fun!

Is there possibility to retag addr:housenumbers without european scheme? (updated) 8 months ago

DaCor, probably yes, but probably not :)

Like was above, there will be counter-examples in many countries (Portugal, France)

Зеленоград has no streets

One example would be Зеленоград

There no "streets" at all here, it uses "Korean" style (block-building addressing):

Is there possibility to retag addr:housenumbers without european scheme? (updated) 8 months ago

but they are so minimal that data users shouldn't treat them separately in most cases.

Again, it is up to data consumers: if they want more features, or if they want simple processing/speed.

addr:system tag

Based on what was said above, I think easiest solution would be in additional tag, not in re-tagging of NA addresses (it would be easy to convince people with statistical background, but almost impossible to explain this minimal difference in styles at OSM scale):

  • addr:system=european
  • addr:system=na
  • addr:system=korean

Yes this tag is absolutely optional, similar to how addr:postcode=* has no effect on most search results. If we see no use in postal codes, It doesn't mean that we should remove this information from database. Same about addr:system, it adds utility and possibilities for those who want them.

To me, OSM would win from clear distinction between european/na/other system.

addr:system=* can be applied to lowest admin_level=* boundaries (biggest suitable number) in hierarchy for simplicity.

Is there possibility to retag addr:housenumbers without european scheme? (updated) 8 months ago

As for European autocompletion, If I enter "123", then:

  • it makes sense to suggest: 121, 125
  • it makes sense to suggest: 123A, 123B, 123C
  • 122, 124 are completely meaningless or should be ranked after other variants (it is unlikely that I will make mistake in odd/even rule)


To implement this is Portugal you have to check if you are not in one of the exceptional areas. In order to do this:

  • every single developer must maintain list: (address style - area)
  • explicit tag can provide a direct answer about what rule set to follow

Does it makes sense why European system is different from NA? They have different use cases (and some statistical properties):

  • NA tells you "X meters from start of the street"
  • European tells you "this building was planned as number X from the beginning of the street"
  • Korean(?) is about "first find this block, then find this building"
Is there possibility to retag addr:housenumbers without european scheme? (updated) 8 months ago

In general, a more clever auto-complete or an user interface:

  • In NA system it will display your GEO position in the road and spatially placed house-numbers (since its matters in NA version)
  • in European system house-numbers won't get you even an estimate of position (order over proximity)

I hope you would argue that region-based addressing (in Korea or in some cities) is completely different from NA and European style? Unfortunately, we don't have all details about this topic.

There should be hint for software "aha this house-number in Korean style". Right now, all developers can do is to re-study topic every time, or make a guess about rules in some territory.

This knowledge should be explicit in data, so it can be processes more robustly.

And yes, we don't have 5-digit numbers, but in what way would that make a difference for data users?

I don't have good ideas, but IN US you should have only numeric keyboard, while in EU you have to use other symbols more often.

We need stats: how often numbers used in NA addresses vs how often they used in European house-numbers.

If there no difference in every single territory, then I give up. Otherwise, it may speed up input of house numbers.

But I was able to hack Nominatim (a second link in the results) :)

Or I don't understand what exactly wrong with this example.

Is there possibility to retag addr:housenumbers without european scheme? (updated) 8 months ago

Europe also has some distance based numbers. You mention Portugal, but I know several villages in France that also use that schema.

Keyword here is "some" villages and "several" villages. I never denied this NA-style is present in Europe, but we should tag it better.

Then there are also streets where numbers take "jumps" on crossings. Not often by 100, but rounding up to the nearest multiple of 10 happens sometimes (note that in taginfo, the numbers 10, 20, 30 are also everytime more popular than 9, 19, 29, which shows my point).

  • Europe RARELY uses Multiples of 10 or skips tens of numbers but
  • NA approach OFTEN uses multiples of 100 or even 1000.

Then we also have things like bis-numbers. Where houses are build between adjecent numbers (f.e. new houses between 29 and 31), and the number gets an extra letter (29A, 29B, 29C, ...).

Additional symbols are typical to both schemes (NA sometimes uses numbers instead of letters)

housenumbers in Europe are far from uniform

In terms of spatial proximity between consequent house numbers? I think they are more uniform, but of course I had no time to observe each of 60M cases.

Other problems is that improperly tagged objects screw statistic and you have no real understanding why or where bases on planet-wide stats

But I doubt it's different enough to need a new schema.

Well maybe not a completely new schema but some tag to split odd/even numbering from proximity-based and grid-based?

Mostly/only in NA you will see 12345 housenumbers

More examples why Europe is so different: