piebro/osm-data huggingface dataset:
scai (2015-09-22 20:15:03+00:00): Du hast dich recht oft verschrieben: amnety statt amenity. Korrigierst du das? Und private=no ist auch komisch, was soll das bedeuten? Dafür gibt es access=yes.
scai (2015-09-22 20:16:24+00:00): Generell wäre es wahrscheinlich besser diese kleinen Parkplätze am Straßenrand durch parking:lane einzuzeichnen statt amenity=parking, siehe dazu https://wiki.openstreetmap.org/wiki/DE:Key:parking:lane. Ist leider etwas komplizierter.
frugivore (2015-09-23 11:39:07+00:00): Ich habe jetzt die Attribute erstmal entsprechend korrigiert. Ob es wirklich Parking lanes sind, ist mir nicht ganz klar, da sie ja deutlich von der Straße abgegrenzt sind. Ich lese mir nochmal die Diskussion durch und schaue mir ein paar Beispiele an.
scai (2015-09-23 12:10:08+00:00): Gut. Ich denke parking:lane ist in diesen Fällen in Ordnung, siehe auch die Beispiele im Wiki: https://wiki.openstreetmap.org/wiki/Key:parking:lane/Examples
Die Parkmöglichkeiten entsprechen meiner Meinung nach eher einem Parken entlang der Straße als einem Parken auf einem abgegrenzten, nicht direkt zur Straße gehörenden Parkplatz. Bei OSM muss man hier und da abwägen, welche Attribute besser zur jeweiligen Situation passen.
frugivore (2015-09-23 19:49:58+00:00): ok, aber was ist wenn sich die Parksituation entlang der Straße ständig ändert, wie in diesem Fall?
scai (2015-09-23 20:09:54+00:00): Was genau ändert sich denn dort ständig?
frugivore (2015-09-28 08:58:46+00:00): Mal darf man ein Stück parken, dann darf man wieder ein Stück nicht parken.
Ich gebe zu, dass die Ansicht der vielen 'P's im Standard-Layer ziemlich überfracheted und unübersichtlich ist, deshalb würde ich das Tag auch ändern, vielleicht 'parking:lane', wie oben schon vorgeschlagen. Dann wird es zwar nicht mehr angezeigt, aber andere Renderer könnten es immer noch auswerten.
scai (2015-09-28 09:21:19+00:00): Achso. Ich denke, selbst wenn das Parken auf einem kurzen Abschnitt mal nicht erlaubt ist, ist parking:lane hier dennoch besser geeignet. Es geht ja hauptsächlich darum zu markieren, dass dort prinzipiell Parkmöglichkeiten existieren.
frugivore (2015-10-06 11:23:36+00:00): Ich habe die parking areas wieder entfernt und die Straße entprechend mit parking:lane getaggt, damit sollte das Problem erledigt sein.
Mateusz Konieczny (2025-07-31 08:44:16+00:00): Hello! https://www.openstreetmap.org/way/111664228/history has maxspeed:advised = 30 mph that was added in this edit
Is it just less-used duplicate of maxspeed:advisory ?
See https://wiki.openstreetmap.org/wiki/Key:maxspeed:advisory

Is there any reason to not change to more widely used key?
raito (2015-09-23 12:07:08+00:00): Not in Brunei. Your edits all in Limbang, Sarawak, Malaysia. Other than that, no comment. Cheers!
chris2map (2015-10-01 16:47:31+00:00): Hallo Herbert3,
mir ist aufgefallen, dass Sie die "maxheight"-Tags von den beiden Fahrspuren der B312 ( www.openstreetmap.org/way/67503665 , www.openstreetmap.org/way/24715045 ) sowie dem Ursulaberg-Tunnel ( www.openstreetmap.org/way/26959770 ) und einer weiteren Stelle südlich ( www.openstreetmap.org/way/75576018 ) gelöscht haben.
Diese waren für die OSM Truck QA Map gedacht.
Es würde mich freuen, wenn Sie den Grund für die Löschung nennen könnten, so dass ich es nachvollziehen kann.
Gruß,
Chris
Herbert3 (2015-10-01 20:41:36+00:00): Sorry, ich glaube da hat mir JOSM einen Streich gespielt. Mach sie bitte wieder rein. Danke
Cascafico (2015-09-23 09:57:19+00:00): Ciao e benvenuto in OSM!

Ho visto che hai modificato degli edifici di Gorizia. Mi permetto di farti dei commenti:

hai assegnato il tag "name=Gorizia" (è il nome del condominio?) ed il tag "addr:housenumber=20" a più edifici: sei sicuro? Eventualmente hanno tutti lo stesso civico, assegna un interno o barrato.

Il tag ele di solito non si assegna agli edifici, ma se la quota della base è 80 metri, lascia pure.
Daniele Mauri (2015-09-23 10:04:33+00:00): Grazie della precisazione, ho corretto eliminando tag=name relativo.
I civici sono tutti uguali ma differiscono per lettera, non ho i dettagli del singolo edificio ma il numerico è corretto.
Confermo quota base come da rilievi e carta tecnica regionale.
Nakaner (2015-10-19 16:22:03+00:00): In direkter Nachbarschaft dieses Lf 6 steht noch mal ein Lf 6 110. Kannst du bitte eine Entscheidung fällen. Beide Signale sind von dir. https://www.openstreetmap.org/node/3754979677/history
bigbug21 (2015-10-19 20:23:41+00:00): Danke. Ist korrigiert.
Thundercel (2015-09-23 01:50:54+00:00): Por que na relação multipoligono do aeroporto os canteiros existentes entre pistas deixaram de fazer parte como membro inner?
naoliv (2015-09-23 01:55:11+00:00): Objetos com função "inner" significam, basicamente, que estão de fora da relação (que não fazem parte dela).
A área do aeroporto inclui o gramado, terminais, etc.
Logo tudo que está dentro da área do aeroporto faz parte dele. Por isso só existe um contorno externo, como outer, sem nenhum "buraco" interno como estava.
naoliv (2015-09-23 01:58:38+00:00): Ou talvez de uma forma melhor, a gente representa a área inteira do aeroporto.
Quanto o gramado e outros objetos estavam como inner, era a mesma coisa que dizer que eles não faziam parte do aeroporto.
Thundercel (2015-09-23 02:24:29+00:00): Vou ter de analisar o que fazer na configuração do Mkgmap porque acabei de compilar um mapa e a representação que existia para as areas verdes do aeroporto deixaram de existir.
Lembro também que existe uma área militar dentro do aeroprto que estava como inner antes e aparecia no mapa. Agora não aparece mais. Essa área é a https://www.openstreetmap.org/way/293257597
naoliv (2015-09-23 02:27:01+00:00): Apesar de ser uma área militar, ela também faz parte do aeroporto?
Thundercel (2015-09-23 02:35:40+00:00): Faza parte do aeroporto, mas é uma área restrita a aeronaves, veiculos e pessoas autorizadas. os veiculos de serviço atorizados a circular internamente pelo aeroporto e até aeronaves civis não podem circular pela area militar.
Estive vendo como procedem com eroporto lá fora. No aeroporto de miami criaram relação multipoligono para os canteiros entre pistas.
Talvez isso seja a saída para apresentação das áreas internas.
naoliv (2015-09-23 02:42:45+00:00): Repare que as áreas dos aeroportos são sempre uma só: http://www.openstreetmap.org/way/113657169 e http://www.openstreetmap.org/way/209681674
Eu acredito que representar as gramas utilizando multipolígonos irá ter o mesmo efeito.
Thundercel (2015-09-23 02:57:59+00:00): São sempre uma só, mas não formatadas como multipoligono. Tanto no aeroporto de Miami como no de Berlin não existe o multipoligono de aeroportto. Em ambos areas internas tem multipoligonos proprios.
Vou analisar o problema do multipoligono esconder o interno e se for o caso farei consulta aos desenvolvedores do Mkgmap.
naoliv (2015-09-23 03:01:08+00:00): Talvez a solução dentro do mkgmap seja algo como o renderizador padrão do OSM faz: ele renderiza objetos menores por cima dos maiores.
No caso do aeroporto, a grama e outros objetos menores são sempre desenhados por cima da área inteira do aeroporto (que é maior).
Se tiver algo que permita fazer isso no mkgmap então resolve.
Thundercel (2015-09-23 03:11:01+00:00): Estou tentando encontrar um aeroporto no mundo delimitado com multipoligono e ainda não encontrei.
É necessário delimitar o do Galeão como multipolígono? 
Partindo do que disse voce dificilmente existirá inner nesse multipoligono dele porque tudo internamente nessa área estará no aeroporto.
Thundercel (2015-09-23 03:14:05+00:00): O aeroporto de berlim, sem ter multipoligono, está em http://www.openstreetmap.org/way/81146061
naoliv (2015-09-23 03:19:13+00:00): Dá pra você ver Viracopos no seu GPS? http://www.openstreetmap.org/way/90834745
Ele é só um caminho, sem usar relação, e possui grama no meio também.
Thundercel (2015-09-23 03:20:25+00:00): O de Londres também não está com multipoligono
http://www.openstreetmap.org/way/121158889
naoliv (2015-09-23 03:22:22+00:00): Ser representado como um caminho único ou relação não é pra influenciar (o resultado é pra ser o mesmo com os dois).
Mas se der pra você ver Viracopos a gente confirma se está tendo diferença.
Thundercel (2015-09-23 03:29:07+00:00): Viracopos no GPS os canteiros entre pistas aparecem.
Thundercel (2015-09-23 03:30:04+00:00): Vou fazer um print da tela do gps para mostrar.
Thundercel (2015-09-23 03:34:06+00:00): http://cocardl.com.br/pv/viracopos.jpg

Viracopos visto no GPS agora. Fica escuro porque após as 1800 hs o gps entra no modo noturno onde os dados escurecem mesmo, mas permite ver os canteiros entre pistas.
naoliv (2015-09-23 03:36:05+00:00): Antes de eu tirar os inner de Galeão o multipolígono estava quebrado. Desconfio se talvez o PBF gerado de hoje ainda não esteja com esse multipolígono aberto.
Dá pra testar com o de amanhã só pra tirar essa dúvida?
Thundercel (2015-09-23 03:44:11+00:00): Ok. Vou testar
Thundercel (2015-09-23 03:49:49+00:00): Não havia antes verificado o galeão e me recordo que fui eu quem desenhou os inner dele, como também os do santos Dummont e campo dos Afonsos. os canteiros no Santos Dummont e os do cammpo dos Afonsos estão sendo vistos normalmente no GPs. Somente o do galeção deiraram de ser vistos hoje.
Quando criei os inner do Galeão o multipoligono não estava quebrado visto pela validação do JOSM e pelo OSM Inspector.
Será que essa mexida geral feita nos bairros pelo Thiago quebrou também o multipoligono?
naoliv (2015-09-23 03:57:24+00:00): Aparentemente sim.
Mas amanhã a gente verifica o resultado com esse polígono.
Thundercel (2015-09-24 01:58:58+00:00): Acabei de compilar e ver no gps o aeroporto.
A sua alteração retirou realmente todos os canteiros e outros objetos que estavam como inner na relação.
naoliv (2015-09-24 02:08:55+00:00): Márcio, tem como postra uma foto disso?
Vou perguntar na lista do mkgmap.
Desconfio que exista algo errado nele que não está entendendo a relação.
Thundercel (2015-09-24 02:24:52+00:00): Em http://cocardl.com.br/pv/galeao.jpg disponibilizo print do gpstela do GPS mostrando o galeão, sem os canteiros após a retirada dos inner.
Em http://cocardl.com.br/pv/santos_dumont.jpg do Santos Dumont mostrando os canteiros por mim desenhados e constante como inner na relação.
Thundercel (2015-09-24 02:30:38+00:00): Analisando o poligono por voce deixado no OSM Inspector ele reporta

WARNING
Touching inner rings
Relation #3896781

O que significa esse aviso warning?
naoliv (2015-09-24 02:34:08+00:00): "Touching inner rings" é quando o caminho outer encosta em algum caminho inner. Isso acontecia antes. Acho que o inspector ainda está com resultado anterior a essa modificação.
Thundercel (2015-09-24 02:46:44+00:00): Observando o Santos Dumont no OSM Inspector não é apresentado nenhum erro para ele, entretanto identifico que nele não foi criado multipoligono de aeroporto e por essa razão os canteiros aparecem.
O campo dos Afonsos, https://www.openstreetmap.org/relation/4760348 , serve melhor de exemplo por existir nele a relação do aerodromo como outer e os canteiros centrais como inner. Tudo aparece normalmente no gps e se desejar tiro print dele no aparelho.
naoliv (2015-09-24 02:48:37+00:00): O Campo de Afonsos também precisa arrumar (não pode ter esses inner, já que tudo faz parte do aeroporto).
Enviei mensagem pra lista do mkgmap, pra ver se não é problema na hora de gerar o mapa (o que desconfio).
Thundercel (2015-09-24 02:51:37+00:00): Em http://cocardl.com.br/pv/afonsos.jpg esta o print da tela do gps onde o aerodromo do Campo dos Afonsos que tem a relação multipoligono, estampa normalmente os canteiros inner dessa relação.
Thundercel (2015-09-24 02:54:02+00:00): Se existir problema esse é no MKGMAP e não na nossa geração porque para teste gerei um mapa empregando os styles default do Mkgmap e disponibilizados junto com ele.
naoliv (2015-09-24 02:55:05+00:00): O problema aqui é que se deixar com os trechos internos com inner, visualmente o mapa ficará certo, tanto aqui no OSM quanto no Garmin.
Mas estará com significado errado: será entendido que tudo o que está com função inner não faz parte do aeroporto.
Não tem erro no polígono pelo JOSM, pelo osmose e nem pelo renderizador padrão.
Justamente por causa disso que desconfio que o mkgmap esteja tratando de forma diferente a relação de uma área fechada.
Vamos aguardar resposta na lista para ver.
Thundercel (2015-09-24 03:23:22+00:00): Interessante que até agora não encontrei lá fora aeroporto sendo tratado como multipoligono.
Em http://wiki.openstreetmap.org/wiki/Aeroways tem exemplos de aeroporto e um muito complexo em Londres, o London Heathrow.
Esse aeroporto está delimitado por way e pode ser visto em https://www.openstreetmap.org/way/185882029
Estoud eduzindo que lá fora não empregam relação para aeroporto devido ao que constatamos no Galeão ao empregarmos.
Confesso que para mim não está fazendo sentido ter o Galeão em relação com somente membros outer nela, sem inner.
Se está causando problema porque manter essa relação? Por que não fazemos a semelhança do que fazem lá fora, sem relação?
naoliv (2015-09-24 03:31:45+00:00): Ele estar como relação não é errado.
Tem alguns dos caminhos dele que são compartilhados com outras relações (e por isso não tem uma área só para ele).
Parece mais mesmo um problema do mkgmap.
naoliv (2015-09-24 10:59:04+00:00): Márcio, tem como gerar um mapa usando o estilo padrão?
Thundercel (2015-09-24 11:41:56+00:00): Eu citei anteriormente a voce que já havia testado gerando um mapa com o estilo padrão do Mkgmap e deu o mesmo erro.
Me envia por email seu telefone que te explico o que ocorre no estilo padrão.
Meu email thundercel@gpsinfo.com.br
Por aqui teria de escrever muita explicação.
Thundercel (2015-09-24 11:48:51+00:00): Se tiver skype seria ainda melhor porque por ele, conectados, eu compartilharia minha tela para voce acompanhar as explicações.
Meu usuário no skype é Thundercel
naoliv (2015-09-24 11:50:39+00:00): Vou te mandar e-mail.
Thundercel (2015-09-24 11:57:03+00:00): aguardando...
naoliv (2015-09-24 12:04:50+00:00): Mandei. Acabei esquecendo o assunto do e-mail, mas vê se você recebeu.
Thundercel (2015-09-24 12:16:36+00:00): Não recebi o email com o telefone.
ViriatoLusitano (2015-09-23 10:55:40+00:00): Thanks wambacher!
sroebuck (2015-09-22 22:01:01+00:00): Added addresses to Greenbank Gardens - nothing to do with Aberfeldy!
literan (2015-09-23 12:45:40+00:00): Остановки вообще не так обозначаются :-((( Правильный набор тегов: bench=yes
bus=yes
highway=bus_stop
name=Улица ...
public_transport=platform
shelter=yes
Tararan (2015-09-23 12:59:47+00:00): Тегов на чём?

На точку ставил заготовку JOSM, на shelter — то, что нашёл в вики (только там building, кажется, не было).
Tararan (2015-09-23 13:04:45+00:00): На https://wiki.openstreetmap.org/wiki/Key:public_transport#Platform_2 написано: «shelter yes/no, If there is a shelter that is not tagged separately with amenity=shelter. »
Tararan (2015-09-23 13:14:31+00:00): Заготовка JOSM — Transport/Public Transport/Platform.
literan (2015-09-23 13:24:01+00:00): отдельный тег для Shelter - это вообще лишнее здесь (оно для убежищ, сторожек в тайге, горах). Что касается остановок, в заготовках JOSM есть старая схема, и новая схема. Новая более правильна, старая отображается на рендерерах. Я вам дал одно + другое, так что и волки целы, и овцы сыты :)) Можете, конечно, только новую схему использовать, но на osm.org остановки тогда не будут видны.
literan (2015-09-23 13:24:59+00:00): Да, это я вам теги для точки остановки дал, т.е. там где остановочный павильон. Если захотите сами маршруты прописывать, то без поллитры точно не разберетесь, я целый день разбирался, и то, подглядываю у других. Там сложный набор отношений делается.
Tararan (2015-09-26 20:01:41+00:00): Маршрут 575 мог снова появиться у другого перевозчика:  https://www.openstreetmap.org/changeset/34208007
naoliv (2015-09-23 01:39:50+00:00): Rodrigo, quando for traçar prédios e outras áreas, não conecte eles nas ruas. Isso é errado. Apenas desenhe a área real deles, sem conectar ou grudar nas vias.
Johnny Mapperseed (2016-12-13 09:38:44+00:00): Could you elaborate more on the park in this area please? Thank you!
amykyta3 (2016-12-13 18:32:04+00:00): Sure!
It is a private scouting campground that I frequent. I may still have some survey information that I can add.
Johnny Mapperseed (2016-12-16 19:25:32+00:00): Cool! Thank you so much! ^_^
GerdP (2015-11-24 14:37:06+00:00): Hi there!
I fear something went wrong here:
layer=hedge on a bridge 
I tried to correct it, but have no idea where the hedge is:
https://www.openstreetmap.org/changeset/35551799
RSergei (2015-09-24 11:51:17+00:00): Правильно будет Пражская улица - если название улицы прилагательное, то оно стоит первым, если существительное то вторым. Почитайте по ссылке которую я Вам давал касаемо адресов.
К примеру правильно Пражская улица, но улица Строителей.
Далее, я так понимаю улицу Строителей переименовали в Пражскую, в таком случае надо поменять название не только на домах, но и на линии самой улицы
Supaplex (2015-09-23 10:19:51+00:00): 大安第九公墓還在嗎？我有祖先的墓已經遷走了
siaoyo (2015-09-23 18:45:15+00:00): 原來是根據「臺北市103年度民族掃墓期間加強墓地防火保林宣導警戒工作執行計畫」的附件「103 年度臺北市合法公立公墓地區資料表」
https://www.google.com.tw/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0CCgQFjACahUKEwiQofLw443IAhUClJQKHYL9AGs&url=http%3A%2F%2Fwww.wfsh.tp.edu.tw%2Fpublish%2Fget_file.asp%3Fpub_no%3D0A0A35327DE30E11181F%26file_no%3D1&usg=AFQjCNEnXNyrhBd_CrdX5fbe9BA5pnxz1Q&sig2=MPQqmtKmHFyoLWwuGh-ybQ
有「大安第九公墓」，位於大安區辛亥隧道北端右側第二殯儀館及自來水廠後方山坡地，面積478,572平方公尺。再參考空照圖來畫。
不過，台北市的公墓近幾年都在遷葬，看資料應該是只會留陽明山第一公墓和富德公墓。
大安第九公墓部份，google到102年12月23日有公告要部份墓區遷葬，並不是全部遷葬。
http://mso.gov.taipei/ct.asp?xItem=70766360&ctNode=49847&mp=107011
同一案，104年4月24日又有修正公告一個月內未遷葬的部份會火化，存放在陽明山第一公墓的納骨塔。
http://mso.gov.taipei/ct.asp?xItem=102915111&ctNode=49847&mp=107011
所以就資料上來看大安第九公墓應該還在，只是面積變小了。最好實地看看會比較清楚。
Mloni (2015-11-12 17:59:47+00:00): Hallo soemisch,
wie kommst du dazu dass es am westlichen Oskar-von-Miller-Ring einen Radweg gibt
 (http://www.openstreetmap.org/way/86334703/history )? Und noch dazu beidseitig in einer Einbahnstraße? Der soll doch erst in 5-6 Jahren gebaut werden!
Bitte prüfe die Infrastruktur doch auch vor Ort auf ihren Ausbaustand.

Warum bekommt die Tunnelzufahrt (motorroad) ein use_sidepath? Es gibt keinen Seitenweg - allenfalls einen Schrammbord. Fuß- und Radverkehr sind hier grundsätzlich verboten! https://www.openstreetmap.org/way/30761501/history

Im Bereich der Straßenquerung 
https://www.openstreetmap.org/way/85004757/history ist das bicycle=use_sidepath bis auf Weiteres ebenfalls völlig falsch da es keinen parallelen Radweg gibt und der Radverkehr hier auf der Straße fahren muss!
Seid doch bitte etwas sorgfältiger bei euren großflächigen Änderungen.

Das gleiche gilt neben vilen anderen Teilabschnitten z.B. hier:
https://www.openstreetmap.org/way/241324029/history
Es ist einfach falsch!

Schöne Grüße
Mloni
soemisch (2015-11-16 09:30:27+00:00): Hallo Mloni, Danke für Deine Meldung. Ich habe nach der Kontrolle die unnötigen Tags wieder gelöscht. Viele Grüße, Lars
soemisch (2015-12-10 11:55:00+00:00): Hallo Mloni, wir hatten den Auftrag für den Radroutenplaner an den Münchener Straßen die vorhandenen Straßen, Rad- und Fußwege mit den von Dir beanstandeten Tags zu versehen. Diese Arbeit und welche Tags benutzt werden sollen wurde mit der Community verabredet. Also muss es dort schon vorher einen Radweg, den "aktualisiert" habe, gegeben haben. Selten habe ich Objekte entfernt oder hinzugefügt. Ich freue mich und finde es richtig, wenn Du durch Deine Ortskenntnis die OSM-Daten korrigierst. Viele Grüße, Lars
kayle (2015-09-23 09:03:05+00:00): Ahoj, 
poprosím ťa keď edituješ dávaj pozor, aby si nepresunul/nespojil nesúvisiace veci. Tu sa ti podarilo spojiť pizzeriu s potokom :)

A ak môžem poprosiť keď ukladáš zmeny tak pod "Krátky popis ukladaných zmien" napíš asi čo sa menilo (ako napr.: nové POI, zarovnanie ciest, nové budovy, a pod) v prehľade zmien sa potom lepšie orientuje ako keď tam je všade iba "(bez komentára)".

Ďakujem
masnak (2015-09-23 15:13:29+00:00): Ahoj.
Dík za upozornenie. Fakt neviem ako sa mi podarilo spojiť pizzeriu s potokom, zrejme pri posune mapy a nevšimol som si to. Pre tvoju informáciu som pridal názov obecného úradu a budova, kde je knižnica je oficiálne urbársky dom. Do budúcna budem komentovať aby bolo zrejmé, o čo ide. ...ale tá pizzeria je haluz :-(... a nie je už Josip.
kayle (2015-09-23 16:07:46+00:00): Stane sa.
Videl som aj ostatné úpravy, ale tie boli bezchybné, tak som ich nemal potrebu komentovať.
Durko_freemap (2015-09-24 09:10:10+00:00): Ahoj, tu si doplnil: addr:housenumber=763/2c, ale consr.=766, ktore je spravne? 763 ci 766. Dik
masnak (2015-09-24 09:18:33+00:00): Spravne je to co som doplnil na 100 %. vedla je cafe Lenka 766/2b 100 %
Postupne opravim - upravim a doplnim aj ostatne.
Durko_freemap (2015-09-24 09:22:22+00:00): ja doplnim/opravim, lebo pridavam aj tag addr:streetnumber, drzime liniu v zmysle http://wiki.freemap.sk/cislabudov
masnak (2015-09-24 09:25:53+00:00): vynasnazim sa :)
SomeoneElse (2015-09-23 20:22:41+00:00): Hi - just for info, this changeset included a node at latitude 0, longitude 0.  I've deleted it.
Zbigniew_Cz (2015-09-23 18:18:24+00:00): Przeszkadzały Ci w czymś te adresy? Jeść wołały?
jacek_zwik (2015-10-29 17:55:50+00:00): Mam prośbę. Naniosłem Hanulin. Czy możesz zweryfikować tory. Żródło skąd wziąłem układ torów jest w uwadze (czerwonej) w okolicy PKP Energia. Pozdrawiam
user_717069 (2015-11-06 11:04:43+00:00): W swoim czasie na pewno to zrobię.
mavl (2015-09-23 17:44:57+00:00): Здравствуйте.
Расскажите, по каким источникам вы сдвигаете дома? Например, дом Менделеева 7 вами сдвинут на 3 метра. На спутниковых снимках Bing и MapBox этого дома (и соседних) нет, а вы так уверенно его сдвигаете. Также абсолютно бесполезно добавление для него тега addr:city=Тюмень. То, что этот дом относится к Тюмени понятно из того, что он входит в границу города Тюмень.  

Я этот дом добавлял по трекам с навигатора по путевым точкам, которые снимал с углов дома. Точность 3-5 м. А вы как определили его координаты?

С гаражом по адресу Зелинского 16 с1 вообще странно. Вы удалили тег building. Это неправильно, потому что это именно одноэтажное здание. Добавили для него amenity=parking. Но ведь это не стоянка для всех желающих, а гараж для жильцов соседних домов. Сейчас тег building:levels=1 остался без тега building. Это логическая ошибка.  

Считаю, что этот пакет правок карту не улучшил, а ухудшил и его можно отменить. Новой информации не добавлено, есть только необъяснимые сдвиги зданий и появление несогласованных тегов на объектах.
pesec (2015-09-24 04:09:51+00:00): В пакет правок входит не только сдвижка домов, но и добавление новых объектов.
В типах объектов вообще нехватка данных. На выбор либо гараж, либо парковка. Понятия "многоуровневая стоянка для автомобилей" отсутствует. От сюда и путаница с тегами.
Посадка домов определяется визуально по картам ДубльГИС как наиболее актуальным. Наличие многих домов неоспоримо, т.к. они являются непосредственно объектами застройки нашей компании.
Смею заметить, что до этого пакета правок информация по домам была куда более ошибочна и ничтожна.
При необходимости его можно поправить.
mavl (2015-09-24 04:29:59+00:00): Использовать данные 2ГИС в OpenStreetMap нельзя, так как 2ГИС не давал разрешения на использование своих данных в OSM.

Выходит, что интересы вашей компании не совпадают с интересами OSM. Мы пытаемся создать свободную карту и не занимаемся плагиатом.

http://www.openstreetmap.org/copyright

Нарушение авторских прав

Напоминаем участникам сообщества OSM, что добавление данных из любых защищённых авторским правом источников (например, с Google Maps или печатных карт) не должно проводиться без явного предварительного согласия правообладателей.  

Также почитайте эту ветку форуму http://forum.openstreetmap.org/viewtopic.php?id=5257

Я попросил других участников высказать своё мнение об этом пакете правок. Но раз вы используете 2ГИС, то придётся удалить все добавленные вами данные.

> Смею заметить, что до этого пакета правок информация по домам была куда более ошибочна и ничтожна.  

Это понятно. У нас ещё даже не все населённые пункты Тюменской область есть.

"многоуровневая стоянка для автомобилей" - это прежде всего здание. Но тег building вы зачем-то удалили.