For example, “payment:troika” was discussed deep in the public trasport thread http://forum.openstreetmap.org/viewtopic.php?pid=596732#p596732

http://taginfo.openstreetmap.org/keys/payment%3Atroika#overview

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

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

e.g.

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.

Thank you tyr!

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

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 osm.org 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.

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

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

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

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

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

Ту же экосистему https://en.wikipedia.org/wiki/Amazon_rainforest

5,500,000 km2

Можно хоть тысячами километров обозначать, хоть самыми грубыми геометриями: https://en.wikipedia.org/wiki/File:Amazon_rainforest.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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).

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.

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)

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.

Examples:

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)” osm.org/user/Meersbrook/history 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!

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 Зеленоград

osm.org/relation/1988678#map=13/55.9792/37.1920

There no “streets” at all here, it uses “Korean” style (block-building addressing): osm.org/way/167350593/history

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.

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)

BUT!

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”

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.

osm.org/way/311932649

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

• osm.org/search?query=Bosstraat%2C%202#map=19/50.92346/3.06045
• osm.org/search?query=Bosstraat%202#map=19/50.92346/3.06045

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

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:

• http://overpass-turbo.eu/s/eEG
• http://overpass-turbo.eu/s/eEJ
• http://overpass-turbo.eu/s/eEM

Gre-kow, молоток!

Вадимом Радченко большое спасибо! Свежие снимки всегда пригодятся для целей OSM!

По последнему абзацу. Шутка в том, что шаблоны эти нафиг не нужны. Не было бы одарённых админов в лице Harry Wood, глядишь и попробовали бы расширение установить:

https://www.mediawiki.org/wiki/Extension:Semantic_Forms https://habrahabr.ru/post/181474/

Ничего неподъёмного там нет, наоборот всё упрощается для пользователей.

Nice to see my edits in more visual way! :) There many more default shortcuts uncovered by this image.

Anyone can join editing this (still incomplete) page: https://josm.openstreetmap.de/wiki/Shortcuts!

а эти самые переходные дорожки отмечаем, что они являются боковыми для проезжей части footway=sidewalk

Не совсем точно, а может быть и вредно.

highway=footway + footway=sidewalk некоторыми в России обозначался для тротуаров “встык” к проезжей части. Это более точное определение.

Зачем нужно “встык” и “по другому”? - потому что в ПДД есть термин “обочина” - потому что по “обочинам” часто ходить опаснее чем по обычным highway=footway (маршрут можно не прокладывать по footway=sidewalk)

С подходом footway=sidewalk на “любом отмеченном тротуаре отдельной линией” эти преимущества теряются. Поэтому указывайте хотя-бы в description “встык к ПЧ” либо тег придумайте если видите этот подход.

Ещё раз, классифицировали на: 1. highway=footway - любые тротуары 2. highway=footway + footway=sidewalk - тротуары “встык” к ПЧ