Re: [Talk-at] OSM Gebäude, Dachfläche oder Grundriss

2020-12-17 Diskussionsfäden Johann Haag
Am Do., 17. Dez. 2020 um 14:43 Uhr schrieb Kevin Kofler via Talk-at <
talk-at@openstreetmap.org>:

> Stefan via Talk-at wrote:
> > Im Grunde entnehme ich deiner Aussage, dass du hier ohne Ahnung oder vor
> > Ort wissen einfach ratest, wie viel hier das Dach überstehen könnte und
> > zeichnest dann irgendetwas ein. Und löscht einfach so Gebäude, "weils ja
> > eh neu gebaut sein könnte".
> >
> >
> https://www.openstreetmap.org/changeset/77457331#map=17/47.66087/12.38632
> > Und das Beispiel ist auch grandios. Dir wurde schon mehrfach erklärt,
> > warum man den Landuse nicht aussparen sollte um "Eine Straßenfläche
> > anzuzeigen". Noch dazu hast dann teilweise nicht mal die Wege dazu
> > eingezeichnet und damit hat man einfach weisse Flächen in OSM. Dir wurde
> > sogar erklärt, was du statt dessen machen könntest um das korrekt zu
> > machen. Hier im Forum, wo auch auf die Mailingliste verwiesen wird
> > https://forum.openstreetmap.org/viewtopic.php?id=70628 Im Grunde ein
> > Paradebeispiel für tagging für den Renderer.
>
> Solche Beispiele (sinnloses Löschen (= Vandalismus) und Neuzeichnen,
> eindeutiges Tagging für den Renderer usw.) solltest du melden zwecks
> Revert,
> oder sogar einfach selbst reverten. Nur eine allgemeine Kritik wird in
> diesem Fall erfahrungsgemäß leider nicht viel bringen.
>
> Und Johann, dich kann ich nur noch einmal ersuchen, dich nicht über den
> Mailinglisten-Konsens hinwegzusetzen, sondern Kritik ernstzunehmen!
>
> Kevin Kofler
>

Hallo Kevin,
Tipp: prüfe einen in den Editor JOSM geladenen Bereich vor Überarbeitung
erst mittels Suchstring timestamp:2018/2020 auf Aktualität
So bekommst du einen guten Überblick darüber, welche Edits jeweils aktuell
sind und daher besonders wertvoll sind.
Ich möchte darauf hinweisen dass ich das Thema mit einer Frage gestartet
habe, leider einige Mailing User nicht bereit sind auf die eigentliche
Frage einzugehen, sondern lieber polemisieren.
Erneut die Frage. Uns stehen hochwertige Luftbilder zur Verfügung, laut OSM
Wiki Empfehlung ist der Gebäudegrundriss zu Mappen. Wir kennen den regional
ortsüblichen Dachüberstand, warum ziehen es mapper dennoch vor das Luftbild
in grotesker weise zu überzeichnen, und reagieren auf den Hinweis auf die
OSM Wiki Empfehlung mit negativen Emotionen.

Grüße Johann




>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>


-- 
Mst. Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at


Re: [Talk-at] OSM Gebäude, Dachfläche oder Grundriss

2020-12-17 Diskussionsfäden Johann Haag
Am Do., 17. Dez. 2020 um 23:14 Uhr schrieb Robert Kaiser :

> Johann Haag schrieb:
> > Neben der Garagenzufahrt eignen sich als weiteres Indiz der jeweilige
> > Gebäudeanschluss zu Nebengebäuden. Zieht man den regional üblicherweise
> > bekannten Typischen Dachüberstand ab, so gelingen solche Anschlüsse auch
> > ohne künstliche Erker oder andere Verrenkungen.
>
> Sorry, aber OSM ist kein Ratespiel. Wir sollten nach bestem Wissen und
> Gewissen das einzeichenen, was wir WISSEN. Wenn wir nur das Dach wissen,
> weil wir von Orthofots abzeichnen, dann ist es gut genug, das zu nehmen.
>

Hallo Robert, uns per OGD Gesetz zur Verfügung gestellten Luftbilder, (also
vom Österreichischen Steuerzahler bezahlte Luftbilder und andere Geodaten)
werden ungefähr alle drei Jahre aktualisiert. Daher ist auch das
regelmäßige aktualisieren von OpenStreetMap durchaus zulässig und sinnvoll.
Speziell dann wenn wie in Salzburg vorliegend, bereits eingezeichnete
Gebäude in grotesker weise -man kann durchaus von einem generellen
Fehlerzustand sprechen- das Luftbild überzeichnen, und so das erfassen
weiterer Details wie Gebäudezufahrten sowie Wege erschweren. Gebäude welche
meterweit das Luftbild überragen, sind einfach objektiv falsch, da hilft
auch keine angeblich behauptete Vor Ort Erhebung, welcher auch in
entsprechenden Changeset Kommentaren von Negreheb fehlt.
OpenStreetMap ist wie alle Karten ein dynamisches und lebendiges Projekt,
und es wäre absurd auf regelmäßige aktualisierungen zu verzichten .
Ich prüfe daher genau, ob ein bereits erfasstes Objekt vor erneuter
Veränderung nicht eventuell neuer als das Luftbild ist. Solche Edits haben
selbstverständlich einen besonderen Wert, und sind unangetastet zu
belassen.

Also eine Bitte an in der Stadt Salzburg aktive Mapper, sofern Details aus
Vorort Erhebungen stammen, ist dieser Umstand den Regeln von OpenStreetMap
entsprechend unbedingt im Changeset Kommentar anzuführen.
Grüße Johann


Wenn du nicht selbst vor Ort warst und das ausgemessen hast, oder einen
> (für die Übernahme erlaubte) Datenquelle hast, die eindeutig besser ist,
> dann ändere nicht Dinge, weil du *schätzt*, dass es so sein könnte.
> Wenn du der erste bist, der das Haus einzeichnet, dann kannst du das
> machen, weil du nach bestem Wissen und Gewissen versuchst, das hin zu
> bekommen. Aber wenn es schon da ist, und die Geometrie nicht auf Grund
> des WISSENS in verfügbaren Quellen zu verbessern ist, dann lass es
> lieber, wie es ist. Weniger Arbeit und eine nur geschätzte
> "wahrscheinlich-möglicherweise" Verbesserung ist keine eigentliche
> Verbesserung und bringt niemand was, schadet nur der Community, weil
> sich der Mapper, der das vorher eingezeichnet hat, übergangen, wertlos
> oder auf den Schlips getreten fühlt.
>
> KaiRo
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>


-- 
Mst. Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at


Re: [talk-cz] Jak slepy import obcas dokaze znicit mapu...

2020-12-17 Diskussionsfäden r00t via talk-cz
Ahoj Mirku,

> Tak je to opraveno.
Diky za opravu a taky za alespon castecne vysvetleni toho co se stalo. Import 
jsem tady podeziral
nepravem, ale z changesetu to proste na import vypadalo.

Je jasne ze OSM je mapa kterou muze editovat kazdy a tak se proste podobne 
chyby obcas stat mohou.
Otazka spis je, co se s tim da delat? Pokud se tohle stane v oblasti kterou 
nikdo nas zrovna
aktivne nesleduje a nevyuziva, zustane podobny problem v mape treba nekolik 
let. A zadny z nastroju
jako OSMCha nebo Achavi ten puvodni changeset nevidi jako podezrely - protoze 
proste nijak divny neni.
I kdyz asi hromadne prejmenovani hodne prvku, co melo puvodne vlastni jmena, na 
jedno a to same, by
nejaky ten red-flag pridat mohlo.

Ale stejne tak neznam zadny nastroj co by kontroloval, jestli ulice ve meste se 
stejnym jmenem navazuji
na sebe - hodne stejne pojmenovanych kousku, co nenavazuji na sebe, vetsinou 
znamena ze je neco spatne.
Podobnou kontrolou by se asi prislo na vic chyb.

Protoze jinak je to jenom o nahode, kdy clovek na neco takoveho nahodou 
narazi...

r00tcz


___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


Re: [Talk-at] OSM Gebäude, Dachfläche oder Grundriss

2020-12-17 Diskussionsfäden Robert Kaiser

Johann Haag schrieb:

Neben der Garagenzufahrt eignen sich als weiteres Indiz der jeweilige
Gebäudeanschluss zu Nebengebäuden. Zieht man den regional üblicherweise
bekannten Typischen Dachüberstand ab, so gelingen solche Anschlüsse auch
ohne künstliche Erker oder andere Verrenkungen.


Sorry, aber OSM ist kein Ratespiel. Wir sollten nach bestem Wissen und 
Gewissen das einzeichenen, was wir WISSEN. Wenn wir nur das Dach wissen, 
weil wir von Orthofots abzeichnen, dann ist es gut genug, das zu nehmen. 
Wenn du nicht selbst vor Ort warst und das ausgemessen hast, oder einen 
(für die Übernahme erlaubte) Datenquelle hast, die eindeutig besser ist, 
dann ändere nicht Dinge, weil du *schätzt*, dass es so sein könnte.
Wenn du der erste bist, der das Haus einzeichnet, dann kannst du das 
machen, weil du nach bestem Wissen und Gewissen versuchst, das hin zu 
bekommen. Aber wenn es schon da ist, und die Geometrie nicht auf Grund 
des WISSENS in verfügbaren Quellen zu verbessern ist, dann lass es 
lieber, wie es ist. Weniger Arbeit und eine nur geschätzte 
"wahrscheinlich-möglicherweise" Verbesserung ist keine eigentliche 
Verbesserung und bringt niemand was, schadet nur der Community, weil 
sich der Mapper, der das vorher eingezeichnet hat, übergangen, wertlos 
oder auf den Schlips getreten fühlt.


KaiRo


___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at


[OSM-talk-fr] accueil nouveaux arrivants

2020-12-17 Diskussionsfäden Georges Dutreix via Talk-fr

Bonjour,

Un petit témoignage. Suite à un message ici, je regarde de temps en 
temps sur OSMCha les "review requested" et les "new mapper" sur la 
France (je me suis mémorisé un filtre).
Cela permet de détecter quelques erreurs et de les signaler avec 
bienveillance, mais aussi tout simplement d'envoyer un "bienvenue" et un 
"merci".
Sans beaucoup d'efforts, on peut souhaiter la bienvenue à quelques 
personnes chaque semaine. Les retours quand il y en a sont en plus 
agréables :-)


Bien cordialement,
georges
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] rond-point et bd cassé à Rennes

2020-12-17 Diskussionsfäden Éric Gillet

Le 16/12/2020 à 14:08, Georges Dutreix via Talk-fr a écrit :

Bonjour,

je crois qu'il y a des habitants de Rennes sur cette liste.
Un utilisateur a cassé un rond-point et transformé le bd de 
Yougoslavie en chemin piéton. Je ne sais pas trop ce qu'il a voulu faire.

Je préfère vous laisser regarder si vous êtes du coin.

https://www.openstreetmap.org/changeset/95934608#map=18/48.08807/-1.65935


Bonjour,

Merci pour le signalement ! J'ai fait quelques amélios 
 grâce aux photos d'un 
ami. Il reste du nettoyage à faire sur Boulevard Louis 
Volclair/Boulevard de Yougoslavie et sur la partie nord de l'Avenue des 
Pays-Bas.


J'ai corrigé aussi quelques trajets de bus 
.


Éric

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [talk-cz] Jak slepy import obcas dokaze znicit mapu...

2020-12-17 Diskussionsfäden Mirek Dlask
Tak je to opraveno.
https://www.openstreetmap.org/changeset/96026703
V dobách kdy bylo hodně nepojmenovaných ulic jsem měl vrstvu ulic z RUIAN,
ze které jsem v JOSM kopíroval potřebné.
Název a ref, pokud byla nutná i oprava geometrie tak celý segment ulice.
Není o páchání dobra, ale o mojí nešikovnosti. Zatím nevím jak jsem vybral
ulice mimo zorný úhel a ty následně přejmenoval.
Mirek

čt 17. 12. 2020 v 18:56 odesílatel r00t via talk-cz <
talk-cz@openstreetmap.org> napsal:

> Ahoj,
>
> Pri prochazeni poslednich poznamek v mape a jejich reseni jsem narazil na
> nasledujici situaci v
> Odolene Vode:
> https://www.openstreetmap.org/#map=16/50.2322/14.4108=N
>
> V mape je asi 30x ulice Akatova, viz vsechny ty poznamky.
> Pokud se podivam na historii zmen k nektere z tech ulic:
>
> https://www.openstreetmap.org/way/26190785/history#map=15/50.2312/14.4129=N
> Je jasne ze za to muze changeset #73855351 od Minimalise:
> https://overpass-api.de/achavi/?changeset=73855351
> Vsechny ulice maji stejne ref:ruian:street. Data na RUIANu a adresni mista
> jsou v poradku, vsechny
> maji spravne ulice, takze nevim co se tam pred rokem stalo.
>
> Ale je uplne jedno odkud se to tam dostalo, co je smutne je ze tohle je
> typicky pripad slepeho importovani
> hlouposti. Rucne by tohle nikdo nikdy do mapy nezadal, 30 stejne
> pojmenovanych ulic proste neni normalni!
> A predtim tam ty ulice byly pojmenovane spravne, uz nejakych 9 let.
>
> Timto bych chtel poprosit Vas vsechny co importuji data do OSM, divejte se
> jaka data do OSM davate!
> Je jedno jestli jde o LPIS, RUIAN, CUZK:KM... takovahle obrovska chyba se
> do mapy nikdy nemela
> dostat. Casto se stava ze import prepise pracne zmapovane oblasti, data
> ktere nekdo osobne posbiral
> v terenu a misto toho se do mapy nasype nejaky paskvil. Jako vzdy nejvic
> skody se da zpusobit tim, ze
> se pacha "dobro" za kazdou cenu...
>
> Vsechny ulice planuju opravit dneska vecer, do te doby se muzete divat na
> tu "nadheru" v mape.
>
> r00tcz
>
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


Re: [talk-cz] Jak slepy import obcas dokaze znicit mapu...

2020-12-17 Diskussionsfäden Mirek Dlask
Ahoj,
nech to, já to opravím.
Jenom pro pořádek. Není to importem. Asi jsem měl nějaký výběr ulic, kterým
jsem všem najednou zkopíroval nesprávné jméno. Jinak si to neumím vysvětlit.
Mirek D.

čt 17. 12. 2020 v 18:56 odesílatel r00t via talk-cz <
talk-cz@openstreetmap.org> napsal:

> Ahoj,
>
> Pri prochazeni poslednich poznamek v mape a jejich reseni jsem narazil na
> nasledujici situaci v
> Odolene Vode:
> https://www.openstreetmap.org/#map=16/50.2322/14.4108=N
>
> V mape je asi 30x ulice Akatova, viz vsechny ty poznamky.
> Pokud se podivam na historii zmen k nektere z tech ulic:
>
> https://www.openstreetmap.org/way/26190785/history#map=15/50.2312/14.4129=N
> Je jasne ze za to muze changeset #73855351 od Minimalise:
> https://overpass-api.de/achavi/?changeset=73855351
> Vsechny ulice maji stejne ref:ruian:street. Data na RUIANu a adresni mista
> jsou v poradku, vsechny
> maji spravne ulice, takze nevim co se tam pred rokem stalo.
>
> Ale je uplne jedno odkud se to tam dostalo, co je smutne je ze tohle je
> typicky pripad slepeho importovani
> hlouposti. Rucne by tohle nikdo nikdy do mapy nezadal, 30 stejne
> pojmenovanych ulic proste neni normalni!
> A predtim tam ty ulice byly pojmenovane spravne, uz nejakych 9 let.
>
> Timto bych chtel poprosit Vas vsechny co importuji data do OSM, divejte se
> jaka data do OSM davate!
> Je jedno jestli jde o LPIS, RUIAN, CUZK:KM... takovahle obrovska chyba se
> do mapy nikdy nemela
> dostat. Casto se stava ze import prepise pracne zmapovane oblasti, data
> ktere nekdo osobne posbiral
> v terenu a misto toho se do mapy nasype nejaky paskvil. Jako vzdy nejvic
> skody se da zpusobit tim, ze
> se pacha "dobro" za kazdou cenu...
>
> Vsechny ulice planuju opravit dneska vecer, do te doby se muzete divat na
> tu "nadheru" v mape.
>
> r00tcz
>
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


Re: [talk-cz] Jak slepy import obcas dokaze znicit mapu...

2020-12-17 Diskussionsfäden Marián Kyral

BTW:

klidně Mirkovi napiš přes OSM zprávy nebo přidej komentář k changesetu.





Marián

-- Původní e-mail --
Od: r00t via talk-cz 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 12. 2020 18:59:51
Předmět: [talk-cz] Jak slepy import obcas dokaze znicit mapu... 
"Ahoj,

Pri prochazeni poslednich poznamek v mape a jejich reseni jsem narazil na 
nasledujici situaci v
Odolene Vode:
https://www.openstreetmap.org/#map=16/50.2322/14.4108=N

V mape je asi 30x ulice Akatova, viz vsechny ty poznamky.
Pokud se podivam na historii zmen k nektere z tech ulic:
https://www.openstreetmap.org/way/26190785/history#map=15/50.2312/14.4129;
layers=N
Je jasne ze za to muze changeset #73855351 od Minimalise:
https://overpass-api.de/achavi/?changeset=73855351
Vsechny ulice maji stejne ref:ruian:street. Data na RUIANu a adresni mista
jsou v poradku, vsechny
maji spravne ulice, takze nevim co se tam pred rokem stalo.

Ale je uplne jedno odkud se to tam dostalo, co je smutne je ze tohle je 
typicky pripad slepeho importovani
hlouposti. Rucne by tohle nikdo nikdy do mapy nezadal, 30 stejne
pojmenovanych ulic proste neni normalni!
A predtim tam ty ulice byly pojmenovane spravne, uz nejakych 9 let.

Timto bych chtel poprosit Vas vsechny co importuji data do OSM, divejte se
jaka data do OSM davate!
Je jedno jestli jde o LPIS, RUIAN, CUZK:KM... takovahle obrovska chyba se do
mapy nikdy nemela
dostat. Casto se stava ze import prepise pracne zmapovane oblasti, data 
ktere nekdo osobne posbiral
v terenu a misto toho se do mapy nasype nejaky paskvil. Jako vzdy nejvic 
skody se da zpusobit tim, ze
se pacha "dobro" za kazdou cenu...

Vsechny ulice planuju opravit dneska vecer, do te doby se muzete divat na tu
"nadheru" v mape.

r00tcz


___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz
"___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


Re: [talk-cz] Jak slepy import obcas dokaze znicit mapu...

2020-12-17 Diskussionsfäden Marián Kyral

Ahoj,

je otázka, zda šlo opravdu o import, nebo chybu při editaci. Třeba si
Minimalis vzpomene.




Data v RÚIANu se zdají v pořádku.


https://openstreetmap.cz/#map=18/50.23500/14.41140=oO2G




Marián




-- Původní e-mail --
Od: r00t via talk-cz 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 12. 2020 18:59:51
Předmět: [talk-cz] Jak slepy import obcas dokaze znicit mapu... 
"Ahoj,

Pri prochazeni poslednich poznamek v mape a jejich reseni jsem narazil na 
nasledujici situaci v
Odolene Vode:
https://www.openstreetmap.org/#map=16/50.2322/14.4108=N

V mape je asi 30x ulice Akatova, viz vsechny ty poznamky.
Pokud se podivam na historii zmen k nektere z tech ulic:
https://www.openstreetmap.org/way/26190785/history#map=15/50.2312/14.4129;
layers=N
Je jasne ze za to muze changeset #73855351 od Minimalise:
https://overpass-api.de/achavi/?changeset=73855351
Vsechny ulice maji stejne ref:ruian:street. Data na RUIANu a adresni mista
jsou v poradku, vsechny
maji spravne ulice, takze nevim co se tam pred rokem stalo.

Ale je uplne jedno odkud se to tam dostalo, co je smutne je ze tohle je 
typicky pripad slepeho importovani
hlouposti. Rucne by tohle nikdo nikdy do mapy nezadal, 30 stejne
pojmenovanych ulic proste neni normalni!
A predtim tam ty ulice byly pojmenovane spravne, uz nejakych 9 let.

Timto bych chtel poprosit Vas vsechny co importuji data do OSM, divejte se
jaka data do OSM davate!
Je jedno jestli jde o LPIS, RUIAN, CUZK:KM... takovahle obrovska chyba se do
mapy nikdy nemela
dostat. Casto se stava ze import prepise pracne zmapovane oblasti, data 
ktere nekdo osobne posbiral
v terenu a misto toho se do mapy nasype nejaky paskvil. Jako vzdy nejvic 
skody se da zpusobit tim, ze
se pacha "dobro" za kazdou cenu...

Vsechny ulice planuju opravit dneska vecer, do te doby se muzete divat na tu
"nadheru" v mape.

r00tcz


___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz
"___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


Re: [OSM-talk-fr] RPG 2.0 2019

2020-12-17 Diskussionsfäden Christian Quest

Le 17/12/2020 à 18:11, ades a écrit :
merci à tous pour vos remarques, en résumé (partiel et/ou partial) 
quelques notes avant de faire (une ou deux communes pour l’instant, 
faut pas aller trop vite)  :


Ça ne concerne que les landuses agricoles et parfois ‘nature’ mais 
plus rares.
A ne faire que si on peut aller sur le terrain pour vérifier. En 
particulier parce que des terrains ne sont plus agricoles.


Ça ne peut fonctionner que si le cadastre PCI est bien calé, autrement 
dit si la différence entre cadastre et ortho est faible (on peut 
vérifier avec les points géodésiques). J’ai tendance à penser que 
moins de 5 pixels de différence (ortho HR) c’est mieux qu’un tracé 
interprétant au pif une limite entre deux objets.


Donc
• exactitude topo des données du RPG : je n’avais pas trop fait 
attention et compris que le RPG renseignait des parcelles cadastrales, 
raté, c’est effectivement « gros doigt » d’après l’ortho (pas plus que 
nombre de contributeurs usant et abusant d’id).


• exactitude des données associées : plutôt pas mal (vérifications  
faites dans mon coin), puis faut pas penser à mal de nos chers 
agriculteurs… ; reste que l’indication précise de la culture n’a 
effectivement pas d’intérêt (sauf cultures permanentes, cf. infra) ; 
faudrait pouvoir maintenir.


• Cultures repérées :
Quasiment tout ce qui est labouré annuellement est renseigné et quasi 
sans ambiguïté ; les vignes et vergers sont renseignés, de même que 
les arbres à fruit ou que les pépinières et les prairies permanentes, 
ou artificielles et temporaires.


• Cadre OSM et nomenclature RPG, correspondance possibles, pour avis…

d’après le code groupe extrait de  : 
https://geoservices.ign.fr/ressources_documentaires/Espace_documentaire/BASES_VECTORIELLES/RPG/DC_DL_RPG_2-0.pdf 
et 
https://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments_cartographiques#Type_de_terrain.2C_usage_.28landuse.29


• code groupe -> osm features

RPG 1 à 9
landuse=farmland crop : pas de précision puisque ça varie une année 
sur l’autre
RPG 11 (jachères)landuse = farmland farmland=disused  ou natural=scrub 
ou crop = no ???
La jachère est souvent temporaire, une année au repos suivie de 
plusieurs années de culture.

RPG 14 (riz)landuse=farmland, crop=rice
RPG 15 à 16 (légumineuses fourrage)landuse = farmland crop non 
renseigné sauf si culture pluriannuelle certaine, voir sur le terrain 
RPG 17 (bois paturés landes…) nature = heath voire nature=grassland 
(cas des estives)

RPG 18 (prairies permanentes) landuse = meadow
RPG 19 (prairies temporaires) landuse = farmland, farmland = meadow ou 
farmland = grass  ou crop= ?
RPG 20 (vergers) landuse = orchads crop=* (à renseigner après vérif 
sur le terrain)

RPG 21 (vignes)landuse= vineyard
RPG 22 (fruits à coque) landuse= orchards crop=*(à renseigner après 
vérif sur le terrain)

RPG 23 (oliviers)landuse=orchards crop=olivier
RPG 24 (autres culture industrielless « sic) » landuse = farmland ce 
ne sont pas des cultures permanentes, dans le cas contraire renseigner 
crop=* (vanille et l’ylang-ylang par exemple -encore que la vanille 
soit souvent uneculture dérobée)) . Vérifier sur le terrain.
RPG 25 (légumes et fleur) landuse = farmland crop=vegetable ou 
crop=flowers
RPG 26 (canne à sucre) landuse = farmland crop=sugarcane (en général 
ça ne bouge pas beaucoup…)
RPG 28 (divers) landuse=farmland sauf pour marais salants, pépinières, 
taillis à courte rotation (landuse=wood) , faut voir au cas par cas …


Faisabilité

• Faisable pour les zones où il n’y a que du Corinne pour le 
remplacer, si sur un polygone Corinne, d’autres landuses agricoles ont 
été saisis, faudra vérifier et à part à la main…

• Faisable pour les zones où Corinne à été viré.
• Faisable si les changesets sont antérieurs, voire très antérieurs au 
RPG ou si les géométries sont du grand n’importe quoi… dommage que 
‘source’ ne soit plus renseigné ou en tous cas de manière tellement 
pas fiable, ni sur l’entité, ni sur la déf. du changeset


Le cas le plus courant c'est du polygone CLC modifié par endroit 
(nouveaux nœuds, nœuds déplacés).


Le polygone CLC non modifiés doivent être rares, ceux antérieurs à CLC 
rarissimes (on n'avait pas tant d'ortho dispo que ça à l'époque).


Charge une zone et dans JOSM cherche: user:CLCF06

Les polygone intacts seront sélectionnés (ile seront rares), par contre, 
tu trouvera sûrement des noeuds non modifiés depuis l'import sur des 
polygones modifiées depuis.




Process
En amont :
Récup du RPG de la zone (faut découper si on ne veut pas se trimballer 
les données d’une région entière), ajouter les tags OSM qui vont bien 
-> déterminer les centroïdes (en gardant les tags) -> récupérer le 
cadastre à jour (c’est trimestriel) -> associer les tags osm du RPG 
aux parcelles cadastrales-> vérifier trous et doublons possibles -> 
regrouper en une unité surfacique les parcelles contigües  de même tag .


Je ne comprends pas trop le lien que tu fais entre parcelles agricoles 
et parcelles 

[talk-cz] Jak slepy import obcas dokaze znicit mapu...

2020-12-17 Diskussionsfäden r00t via talk-cz
Ahoj,

Pri prochazeni poslednich poznamek v mape a jejich reseni jsem narazil na 
nasledujici situaci v
Odolene Vode:
https://www.openstreetmap.org/#map=16/50.2322/14.4108=N

V mape je asi 30x ulice Akatova, viz vsechny ty poznamky.
Pokud se podivam na historii zmen k nektere z tech ulic:
https://www.openstreetmap.org/way/26190785/history#map=15/50.2312/14.4129=N
Je jasne ze za to muze changeset #73855351 od Minimalise:
https://overpass-api.de/achavi/?changeset=73855351
Vsechny ulice maji stejne ref:ruian:street. Data na RUIANu a adresni mista jsou 
v poradku, vsechny
maji spravne ulice, takze nevim co se tam pred rokem stalo.

Ale je uplne jedno odkud se to tam dostalo, co je smutne je ze tohle je typicky 
pripad slepeho importovani
hlouposti. Rucne by tohle nikdo nikdy do mapy nezadal, 30 stejne pojmenovanych 
ulic proste neni normalni!
A predtim tam ty ulice byly pojmenovane spravne, uz nejakych 9 let.

Timto bych chtel poprosit Vas vsechny co importuji data do OSM, divejte se jaka 
data do OSM davate!
Je jedno jestli jde o LPIS, RUIAN, CUZK:KM... takovahle obrovska chyba se do 
mapy nikdy nemela
dostat. Casto se stava ze import prepise pracne zmapovane oblasti, data ktere 
nekdo osobne posbiral
v terenu a misto toho se do mapy nasype nejaky paskvil. Jako vzdy nejvic skody 
se da zpusobit tim, ze
se pacha "dobro" za kazdou cenu...

Vsechny ulice planuju opravit dneska vecer, do te doby se muzete divat na tu 
"nadheru" v mape.

r00tcz


___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


Re: [Talk-at] OSM Gebäude, Dachfläche oder Grundriss

2020-12-17 Diskussionsfäden Stefan Tauner
On Thu, 17 Dec 2020 15:03:07 +0100
Johann Haag  wrote:

> Man findet in der Basemap Digitale Artefakte speziell dort wo es an 
> Gebäudekanten Rundungen gibt. Bizarre Formen welche kein Mensch so zeichnen 
> würde. Das ist für eine basemap durchaus in Ordnung. Die Weigerung einiger 
> Mapper in Osm den Empfehlungen der OSM Wiki folgend zu Mappen ist eine ganz 
> andere Angelegenheit.
> Selbst das ist aber noch in Ordnung, da es sich ja nur um eine Empfehlung 
> handelt. Ein Revert anzuwenden, um vollkommen korrekt auf dem 
> Gebäudegrundriss gezeichnetes wieder zu verschlechtern, das wäre dann 
> jedenfalls Vandalismus.

Mag hier jemand Jeopardy?

 - "Bizarre Formen, welche kein Mensch so zeichnen würde" für 500 bitte.
 - https://ibb.co/3dS8qWw
 - Was ist ein Johann Haag Fuckup Deluxe?
 - €€€

Aber OK, war keine Rundung; das stimmt schon.
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at


[OSM-talk-fr] L’OGC adopte Symcore comme standard des feuilles de style carto

2020-12-17 Diskussionsfäden Christian Rogel
Ouest-France annonce que le chercheur breton, Erwan Bocher (CNRS-Université de 
Bretagne-Sud), associé au Suisse, Olivier Ertz, a convaincu l’Open Geospatial 
Consortium d’adopter le standard Symcore qui a pour but d’offrir une symbologie 
cartographique unifiée a des données géospatiales venant de différentes sources.

Voir article Ouest-France du 17-12 : 
https://www.ouest-france.fr/sciences/un-francais-a-l-origine-d-une-petite-revolution-dans-le-monde-de-la-cartographie-7090069

Voir site d’Erwan Bocher : 
http://r1.bocher.free.fr/index.php?n=Main.Publications

Qui peut nous dire si cela va impacter OSM ?


Christian R.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] RPG 2.0 2019

2020-12-17 Diskussionsfäden ades
merci à tous pour vos remarques, en résumé (partiel et/ou partial) quelques 
notes avant de faire (une ou deux communes pour l’instant, faut pas aller trop 
vite)  :

Ça ne concerne que les landuses agricoles et parfois ‘nature’ mais plus rares.
A ne faire que si on peut aller sur le terrain pour vérifier. En particulier 
parce que des terrains ne sont plus agricoles.

Ça ne peut fonctionner que si le cadastre PCI est bien calé, autrement dit si 
la différence entre cadastre et ortho est faible (on peut vérifier avec les 
points géodésiques). J’ai tendance à penser que moins de 5 pixels de différence 
(ortho HR) c’est mieux qu’un tracé interprétant au pif une limite entre deux 
objets.

Donc
• exactitude topo des données du RPG : je n’avais pas trop fait attention et 
compris que le RPG renseignait des parcelles cadastrales, raté, c’est 
effectivement « gros doigt » d’après l’ortho (pas plus que nombre de 
contributeurs usant et abusant d’id). 

• exactitude des données associées : plutôt pas mal (vérifications  faites dans 
mon coin), puis faut pas penser à mal de nos chers agriculteurs… ; reste que 
l’indication précise de la culture n’a effectivement pas d’intérêt (sauf 
cultures permanentes, cf. infra) ; faudrait pouvoir maintenir.

• Cultures repérées :
Quasiment tout ce qui est labouré annuellement est renseigné et quasi sans 
ambiguïté ; les vignes et vergers sont renseignés, de même que les arbres à 
fruit ou que les pépinières et les prairies permanentes, ou artificielles et 
temporaires.

• Cadre OSM et nomenclature RPG, correspondance possibles, pour avis…

d’après le code groupe extrait de  : 
https://geoservices.ign.fr/ressources_documentaires/Espace_documentaire/BASES_VECTORIELLES/RPG/DC_DL_RPG_2-0.pdf
  et 
https://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments_cartographiques#Type_de_terrain.2C_usage_.28landuse.29

• code groupe -> osm features

RPG 1 à 9 
landuse=farmland crop : pas de précision puisque ça varie une année sur l’autre
RPG 11 (jachères)   landuse = farmland farmland=disused  ou natural=scrub 
ou crop = no ???
RPG 14 (riz)landuse=farmland, crop=rice 
RPG 15 à 16 (légumineuses fourrage) landuse = farmland crop non renseigné 
sauf si culture pluriannuelle certaine, voir sur le terrain RPG 17 (bois 
paturés landes…) nature = heath voire nature=grassland (cas des estives)
RPG 18 (prairies permanentes)   landuse = meadow
RPG 19 (prairies temporaires)   landuse = farmland, farmland = meadow ou 
farmland = grass  ou crop= ?
RPG 20 (vergers)landuse = orchads crop=* (à renseigner après vérif sur 
le terrain)
RPG 21 (vignes) landuse= vineyard
RPG 22 (fruits à coque) landuse= orchards crop=*(à renseigner après vérif sur 
le terrain)
RPG 23 (oliviers)   landuse=orchards crop=olivier
RPG 24 (autres culture industrielless « sic) » landuse = farmland ce ne sont 
pas des cultures permanentes, dans le cas contraire renseigner crop=* (vanille 
et l’ylang-ylang par exemple -encore que la vanille soit souvent une
culture dérobée)) . Vérifier sur le terrain.
RPG 25 (légumes et fleur) landuse = farmland crop=vegetable ou crop=flowers
RPG 26 (canne à sucre) landuse = farmland crop=sugarcane (en général ça ne 
bouge pas beaucoup…)
RPG 28 (divers) landuse=farmland sauf pour marais salants, pépinières, taillis 
à courte rotation (landuse=wood) , faut voir au cas par cas …

Faisabilité

• Faisable pour les zones où il n’y a que du Corinne pour le remplacer, si sur 
un polygone Corinne, d’autres landuses agricoles ont été saisis, faudra 
vérifier et à part à la main…
• Faisable pour les zones où Corinne à été viré.
• Faisable si les changesets sont antérieurs, voire très antérieurs au RPG ou 
si les géométries sont du grand n’importe quoi… dommage que ‘source’ ne soit 
plus renseigné ou en tous cas de manière tellement pas fiable, ni sur l’entité, 
ni sur la déf. du changeset

Process
En amont : 
Récup du RPG de la zone (faut découper si on ne veut pas se trimballer les 
données d’une région entière), ajouter les tags OSM qui vont bien -> déterminer 
les centroïdes (en gardant les tags) -> récupérer le cadastre à jour (c’est 
trimestriel) -> associer les tags osm du RPG aux parcelles cadastrales-> 
vérifier trous et doublons possibles -> regrouper en une unité surfacique les 
parcelles contigües  de même tag .
Avant import :  comparer avec ce qui existe dans osm, dans le cas où il y 
aurait plus d’info dans osm ensuite ça devient « dangereux » :  enlever ce qui 
gène dans OSM et remplacer par le boulot ci-dessus…

Ça ne me parait pas trop difficile à faire, avec un sig puis avec josm, 
peut-être faisable directement dans Josm, mais là je n’en ai qu’une pratique 
basique). 
Par rapport à Osmose, je n’ai tjs pas bien compris ce que fait Osmose, mais si 
la mise en place d’une comparaison entre le travail « amont » et les données 
figurant dans OSM pour indiquer ce qui diverge est quelque chose qu’Osmose 
fait, pourquoi pas, possible alors de travailler sur de plus 

Re: [Talk-at] OSM Gebäude, Dachfläche oder Grundriss

2020-12-17 Diskussionsfäden Johann Haag


Von meinem iPhone gesendet

> Am 16.12.2020 um 21:33 schrieb Thomas Rupprecht :
> 
> 
> Hallo Johann,
> 
> Also die Gebäude in der basemap.at sind definitiv nicht aus den Konturen des 
> Daches aus dem Orthofoto abgeleitet. Zumindest nicht in NÖ und Wien.
> Woher hast du diese Erkenntnis? Hast du ein Beispiel wo das so ist?

Man findet in der Basemap Digitale Artefakte speziell dort wo es an 
Gebäudekanten Rundungen gibt. Bizarre Formen welche kein Mensch so zeichnen 
würde. Das ist für eine basemap durchaus in Ordnung. Die Weigerung einiger 
Mapper in Osm den Empfehlungen der OSM Wiki folgend zu Mappen ist eine ganz 
andere Angelegenheit.
Selbst das ist aber noch in Ordnung, da es sich ja nur um eine Empfehlung 
handelt. Ein Revert anzuwenden, um vollkommen korrekt auf dem Gebäudegrundriss 
gezeichnetes wieder zu verschlechtern, das wäre dann jedenfalls Vandalismus.

Liebe Johann


> Das die Gebäude Geometrie nicht immer 100% der Wirklichkeit entspricht stimmt 
> schon. Aber definitiv nicht abgeleitet aus dem Orthofoto.
> 
> mfg Thomas Rupprecht
> 
> 
>> Am Mi., 16. Dez. 2020 um 21:14 Uhr schrieb Johann Haag :
>> Mir ist aufgefallen dass in dem openstreetmap zur Verfügung gestellten 
>> basemap.at Hintergrund, Gebäudeumrisse aus einem maschinellen Prozess 
>> stammen. Offensichtlich werden Gebäude Konturen der basemap von einer 
>> Maschine vom Luftbild über die Dach Außenkanten ermittelt.
>> Das mag für Behördenkarten genügend sein, in OpenStreetMap sollen Gebäude  
>> hingegen möglichst auf deren Grundriss gezeichnet werden. 
>> 
>> OSM Wiki Zitat: "Wenn möglich sollte der gezeichnete Umriss der Außenwand am 
>> Boden folgen (Grundriss), also z.B. Dachüberstände aussparen. Wird die 
>> Geometrie des Gebäudes aber besonders durch solche freistehenden Formen 
>> definiert, kann statt des Grundrisses auch die überbaute Fläche gezeichnet 
>> werden, also z.B. Balkone, Brücken und Gebäudeteile auf Stelzen 
>> eingeschlossen werden." Ref: 
>> https://wiki.openstreetmap.org/wiki/DE:Geb%C3%A4ude#Umriss
>> 
>> Die Dach Außenkante zu verwenden, ist also in der basemap einem maschinellen 
>> Prozess geschuldet. Warum aber finden wir diese Vorgangsweise meist auch in 
>> OpenStreetMap angewandt. Man könnte natürlich behaupten, solche Umrisse 
>> stammen noch aus Zeiten schlechter Luftbilder. Schaut man sich aber aktuelle 
>> Edits an, so fällt auf, das Zeichnen der Dachaußenkanten ist ebenso aktuelle 
>> Praxis.
>> 
>> Warum beschäftigt mich dieses Thema. Speziell bei Hauszufahrten führt die 
>> Zufahrt zur Garage oft unter einem ausladenden Vordach des Hauses zur 
>> Garage. Ist für das Gebäude nun in OSM die Dachaußenkante gewählt, bleibt 
>> für die Garagenzufahrt dann kein Platz.
>> 
>> Meine Frage: warum übernehmen für Gebäude die starre maschinenbedingte 
>> Vorgangsweise der Basemap, nachdem wir in OSM ja frei in unserer Wahl wären, 
>> und auch OSM Wiki, klar das Zeichnen des Gebäude Grundrisses empfiehlt.
>> 
>> -- 
>> Mst. Johann Haag
>> Innsbruckerstraße 42
>> 6380 St. Johann in Tirol
>> ÖSTERREICH
>> Tel: +43 664/174 7414
>> Mailto:johannh...@hxg.at
>> ___
>> Talk-at mailing list
>> Talk-at@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-at
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at


[Talk-it] Incontro in Jitsi sabato 19/12: come mappiamo in Josm

2020-12-17 Diskussionsfäden mbranco2
Ciao Lista,

Sabato 19/12, h15, ci sentiamo in Jitsi per parlare di Josm, scambiandoci
le best practice che ognuno di noi usa per mappare (magari scoprendo da
altri che quella che noi pensavamo "best" in realtà è migliorabile...) .
Come zona di mappatura opereremo nell'astigiano, raccogliendo l'invito che
allo scorso OsmIt ci avevano fatto gli operatori del NUE 112 (link
). Discuteremo quindi
anche di come coordinarci per poter migliorare la Mappa in quella
provincia, in attesa di poter organizzare dei rilievi sul campo e magari
contattare gli enti locali per ottenere ulteriori dati.

I dettagli dell'incontro sono qui:
https://lists.openstreetmap.org/pipermail/talk-it-piemonte/2020-December/001091.html

Vi aspettiamo, Ciao!
Marco




Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-hr] Import ZET ID-ova od stanica iz GTFS-a

2020-12-17 Diskussionsfäden Janko Mihelić
I imam još jedno pitanje koje moramo zajedno dogovoriti, slažemo li se da
network=* tag kod nas u Zagrebu za ZET promjenimo iz network=local u
"network=Zagrebački električni tramvaj"? Taj tag se koristi za odjeljivanje
ruta koje su za od raznih operatera, pa bi trebali promijeniti kako se taj
tag koristi.

Janko
___
Talk-hr mailing list
Talk-hr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-hr


Re: [Talk-de] Weihnachtskarten 2020

2020-12-17 Diskussionsfäden Andreas Schmidt via Talk-de
Ich möchte einfach mal DANKE sagen.

Andreas

Am 14.12.20 um 15:20 schrieb Frederik Ramm:
> Hallo,
>
> Weihnachten ist dieses Jahr für die meisten etwas anders als sonst, aber
> unverändert gibt's unsere kleine Geofabrik-Weihnachtskarten-Aktion.
>
> Wie schon im letzten Jahr bieten wir Euch hier auf der deutschen
> Mailingliste und im deutschen Forum an, kostenlos eine große Karte von
> einem Gebiet Eurer Wahl auszudrucken und Euch zu schicken.
>
> Das Angebot gilt nur bis morgen (Dienstag) mittag. Wir drucken alle
> Aufträge in der Reihenfolge, in der sie reinkommen, und nur so lange,
> bis wir am Dienstag abend nach Hause gehen. Da bringen wir dann auch
> gleich alles zur Post.
>
> Wenn ihr eine Karte zugeschickt haben möchtet, brauchen wir von Euch:
>
> * entweder ein fertiges PNG (bzw Link zum Download desselben)
> * oder einen Link zu einer Karte, die ihr auf Hartmuts MyOSMatic-Seite
> erstellt habt (https://print.get-map.org/)
> * oder die Koordinaten eines Ausschnitts (alternativ Link zu einem
> Rechteck auf tools.geofabrik.de/calc), dann erzeugen wir ein Bild im
> Standard-Carto-Stil oder um deutschen OSM-Stil
>
> und außerdem
>
> * das Papierformat - wenn nicht anders angegeben, drucken wir "Super A0"
> mit 15035x10559 Pixel, ca 1,30x0,90m
> * die Adresse, wo es hingehen soll. Wir verschicken nur an deutsche
> Adressen, sonst wird der Spaß zu teuer!
>
> Das ganze per Email an weihnachtsdr...@geofabrik.de
>
> Wir drucken die Karte, falten sie, und verschicken sie in einem Umschlag
> im Format B4. Wir übernehmen alle Kosten, auch das Porto.
>
> Die Aktion ist als Dankeschön für die unermüdliche Arbeit der
> Mapperinnen und Mapper in OSM gedacht. Bitte verzichtet darauf, das
> ganze in sozialen Medien weiterzuverbreiten - bis sich das rumspricht,
> ist die Warteschlange eh voll, und es gibt nur lange Gesichter.
>
> Bye
> Frederik
>
> PS: Wer die Karte gern gerollt und nicht gefaltet haben will ODER wer
> einen Versand ins Ausland wünscht: Das geht auch, aber dann müsst ihr
> uns eine entsprechende Post-Briefmarke (für gefalteten Versand ins
> Ausland) oder DHL-Paketmarke "Paket bis 5kg" (für den aufgerollten
> Versand in einer quaderförmigen Schachtel - die Größenbeschränkungen
> beim "2kg"-Paket sind zu knapp) als PDF generieren und zuschicken.
>

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [OSM-talk-fr] un début de OSM - mon commerce

2020-12-17 Diskussionsfäden Yves P.
@ Marc
> test effectué ce matin :
> clic sur un commerce existant
> bouton modifier :-)
> 
Bien vu :)
J'avais onosm.org en tête.

> je pense qu'avant de coder, il serait utile de reprendre l'inventaire
> de ce qui manquent aux outils existant.
> et surtout voir ce que font les outils existant, cela vous évitera de
> coder un nouvel outil parce que la fonction xyz manque...
> alors qu'il existe

A part une éventuelle maquette, on ne code rien. Pour le moment (2e réunion 
mais première formelle) on définit les besoins :
Ceux de la communauté,
Ceux de la cible : les commerçants, et à terme les entreprises, associations.


@ Stéphane et Vincent
>> Autre solution intermédiaire :
>> 
>> Afficher les horaires des différents services (Osm, google, pages jaunes, 
>> etc...). C'est probable que ça intéresse les commerçants de vérifier depuis 
>> une seule page que tout est à jour. Et dans un premier temps, depuis ce site 
>> il ne sera possible que de modifier les horaires Osm. 

C'est prévu mais peut-être pas dit explicitement :)

A partir de l'adresse web saisie, on va moissonner les données sémantiques si 
elles sont présentes (cf. greffon JOSM Microdata scraping 
).
On peut le faire aussi à partir de la page facebook, Page Jaunes, Google…

> rho, j'adore !
> 
> car c'est rendre un service sympa et surtout montrer à quel point cela 
> peut-être simple de changer ses heures d'ouvertures avec OSM :)

Oui et ça peut permettre de :
ne pas ressaisir des informations existantes
montrer les incohérences entre les sources de données (Pages Jaunes, Facebook… 
mais aussi OSM, SIRENE…)

Pour le second point, le moteur de recherche Google remonte une entreprise vers 
le haut de la liste si son référencement naturel (SEO) est bien fait et que les 
infos sont homogènes sur le web.
Cf. Solocal — Google My Business : indispensable en période post-confinement 


__
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-at] OSM Gebäude, Dachfläche oder Grundriss

2020-12-17 Diskussionsfäden Kevin Kofler via Talk-at
Stefan via Talk-at wrote:
> Im Grunde entnehme ich deiner Aussage, dass du hier ohne Ahnung oder vor
> Ort wissen einfach ratest, wie viel hier das Dach überstehen könnte und
> zeichnest dann irgendetwas ein. Und löscht einfach so Gebäude, "weils ja
> eh neu gebaut sein könnte".
> 
> https://www.openstreetmap.org/changeset/77457331#map=17/47.66087/12.38632
> Und das Beispiel ist auch grandios. Dir wurde schon mehrfach erklärt,
> warum man den Landuse nicht aussparen sollte um "Eine Straßenfläche
> anzuzeigen". Noch dazu hast dann teilweise nicht mal die Wege dazu
> eingezeichnet und damit hat man einfach weisse Flächen in OSM. Dir wurde
> sogar erklärt, was du statt dessen machen könntest um das korrekt zu
> machen. Hier im Forum, wo auch auf die Mailingliste verwiesen wird
> https://forum.openstreetmap.org/viewtopic.php?id=70628 Im Grunde ein
> Paradebeispiel für tagging für den Renderer.

Solche Beispiele (sinnloses Löschen (= Vandalismus) und Neuzeichnen, 
eindeutiges Tagging für den Renderer usw.) solltest du melden zwecks Revert, 
oder sogar einfach selbst reverten. Nur eine allgemeine Kritik wird in 
diesem Fall erfahrungsgemäß leider nicht viel bringen.

Und Johann, dich kann ich nur noch einmal ersuchen, dich nicht über den 
Mailinglisten-Konsens hinwegzusetzen, sondern Kritik ernstzunehmen!

Kevin Kofler


___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at


Re: [Talk-de] Karte vom IFZ ohne Quellangabe

2020-12-17 Diskussionsfäden Martin Koppenhoefer


sent from a phone

> On 16. Dec 2020, at 11:33, Hauke Stieler  wrote:
> 
> Wou wou wou, Moment! Die haben innerhalb von unter zwei Stunden geantwortet 
> UND die Website gefixt? Es gibt tatsächlich noch IT-Abteilungen/Entwickler 
> die 
> es drauf haben. Schön zu sehen, dass die Attribution nun stimmt.


stimmt, das war echt blitzschnell. Ich habe auf solche mails auch schon nach 6 
Wochen erst oder nie eine Antwort bekommen. Und bis es gefixt wurde ist ein 
Jahr keine Seltenheit, bei den ganz großen dauert es wohl noch länger, Apple 
hat viele Jahre gebraucht, Facebook sträubt sich immer noch, und bei Mapbox 
kann man sich auch streiten.

Beim IFZ hatten sie es wohl wirklich nur vergessen/übersehen ;-)


Gruß Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [OSM-talk-fr] un début de OSM - mon commerce

2020-12-17 Diskussionsfäden Vincent Bergeot

Le 17/12/2020 à 10:09, Stéphane Péneau a écrit :

Autre solution intermédiaire :

Afficher les horaires des différents services (Osm, google, pages 
jaunes, etc...). C'est probable que ça intéresse les commerçants de 
vérifier depuis une seule page que tout est à jour. Et dans un premier 
temps, depuis ce site il ne sera possible que de modifier les horaires 
Osm. 


rho, j'adore !

car c'est rendre un service sympa et surtout montrer à quel point cela 
peut-être simple de changer ses heures d'ouvertures avec OSM :)


Plusieurs fournisseurs de données, c'est intéressant de pouvoir voir 
l'inhomogénéité (ou pas).


Après MapCompare, OpenhoursCompare :)

bonne journée

--
Vincent Bergeot


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-tr] import hakkında

2020-12-17 Diskussionsfäden Orkut Murat YILMAZ
Selamlar herkese,

Topluluğumuzdan bu konuyla ilgilenen arkadaşlarla bir araya gelerek bir
online görüşme yapsak mı? Ne dersiniz?

İyi çalışmalar dilerim.

On Tue, Dec 15, 2020 at 4:24 PM Roman Neumüller  wrote:

> osmviki'ye göre Corine Land Cover
>   kullanması
> onaylıyor fakat vikinin içeriği iyi okumak lazım.
> Kullanıcı gruplarla temasa girmek lazım fakat bu mailing listesi
> yetmiyebilir - duyduğuma
> göre Face'in Openstreetmap Türkiye da var...
>
> Kolay gelsin ;)
>
> On Tue, 15 Dec 2020 16:01:58 +0300, ahmetlii _ 
> wrote:
>
> > Merhaba. Geçenlerde burada
> > 
> > kullanılabilecek
> > bir metadata olduğunu gördüm. Hem ayrıca veri sağlayıcısı şurada
> > <
> https://land.copernicus.eu/pan-european/corine-land-cover/clc2018?tab=metadata
> >
> > erişim
> > konusunda limit olmadığını gördüm.Türkiye'de OpenStreetMap üzerinden elle
> > haritalanan yer sayısı az ve geniş alanları elle haritalamak oldukça
> > zahmetli. En azından Copernicus'un bahsettiğim lisanslama konusunda
> > problemi olmayan metaverisini kullanıp boş alanları hızlıca
> > haritalasak mantıklı olabilir. Zaten bu konu hakkında imports
> > mailinglistine de yazmayı düşünüyorum. Dipnot olarak şu
> >  bağlantıyı bırakıyorum.
> > Herkese iyi çalışmalar.
> ___
> Talk-tr mailing list
> Talk-tr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-tr
>


-- 
http://orkutmuratyilmaz.com
___
Talk-tr mailing list
Talk-tr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-tr


Re: [Talk-at] OSM Gebäude, Dachfläche oder Grundriss

2020-12-17 Diskussionsfäden Stefan via Talk-at
Hallo Johann,

es ist ein bisschen traurig, dass du OpenStreetMap offensichtlich immer noch 
nicht verstehst. Das ist eine Datenbank. Da sollte möglichst alles rein. Die 
"reduzierte" Ansicht, die du gern hättest, darum muss sich der Renderer 
kümmern, nicht die Datenbank. Du kannst ja selber einen Renderer schreiben, wo 
das der Fall ist.

Im Grunde entnehme ich deiner Aussage, dass du hier ohne Ahnung oder vor Ort 
wissen einfach ratest, wie viel hier das Dach überstehen könnte und zeichnest 
dann irgendetwas ein. Und löscht einfach so Gebäude, "weils ja eh neu gebaut 
sein könnte".

https://www.openstreetmap.org/changeset/77457331#map=17/47.66087/12.38632
Und das Beispiel ist auch grandios. Dir wurde schon mehrfach erklärt, warum man 
den Landuse nicht aussparen sollte um "Eine Straßenfläche anzuzeigen". Noch 
dazu hast dann teilweise nicht mal die Wege dazu eingezeichnet und damit hat 
man einfach weisse Flächen in OSM. Dir wurde sogar erklärt, was du statt dessen 
machen könntest um das korrekt zu machen. Hier im Forum, wo auch auf die 
Mailingliste verwiesen wird 
https://forum.openstreetmap.org/viewtopic.php?id=70628
Im Grunde ein Paradebeispiel für tagging für den Renderer.

Und, wie gesagt, du kannst machen was du magst und wo du magst, solange du 
keinen Müll produzierst, aber wenn du dort anfängst, wo ich gerade systematisch 
durch die Straßen fahre / gehe und Fotos mache und alles detailiert eintrage, 
inklusive sämtlicher Firmen, die vor Ort sind, dann komme ich mir verarscht 
vor. Weil "viel zu tun" gibt es sicherlich in diversen Gemeinden am Land, wo 
sonst niemand tagged, viel mehr. Und der nutzen von dem was du tust (Gebäude 
einzeichnen, Wege ergänzen [oder auch nicht]) ist dort auch wesentlich höher 
als dort, wo jemand mehr oder weniger genau das gleiche (vor Ort!) sowieso 
gerade macht.

Grüße
Negreheb


> Johann Haag  hat am 17.12.2020 10:14 geschrieben:
> 
> 
> 
> 
> Am Do., 17. Dez. 2020 um 00:21 Uhr schrieb Kevin Kofler via Talk-at 
> mailto:talk-at@openstreetmap.org >:
> 
> > > Johann Haag wrote:
> > > Meine Frage: warum übernehmen für Gebäude die starre 
> > maschinenbedingte
> > > Vorgangsweise der Basemap, nachdem wir in OSM ja frei in unserer 
> > Wahl
> > > wären, und auch OSM Wiki, klar das Zeichnen des Gebäude
> > > Grundrisses empfiehlt.
> > 
> > Und wie ermittelst du eben jenen Gebäude-Grundriß? Wenn ich Gebäude
> > einzeichne, kann ich sie auch nur entweder aus einem 
> > Luftbild/Orthofoto
> > abzeichnen
> > 
> > > 
> Ich habe ein paar Beispiel Changesets erzeugt wo man sieht wie ich über 
> die Garagenzufahrt jeweils auf den Gebäudegrundriss schließe.
> 95962680
> 95960289
> 95958904
> 95957407
> 95956524
> 95956392
> Neben der Garagenzufahrt eignen sich als weiteres Indiz der jeweilige 
> Gebäudeanschluss zu Nebengebäuden. Zieht man den regional üblicherweise 
> bekannten Typischen Dachüberstand ab, so gelingen solche Anschlüsse auch ohne 
> künstliche Erker oder andere Verrenkungen.
> Wie man an meiner Chronik sieht, bemühe ich mich jeweils sehr die Edit- 
> Historie eines Objektes zu erhalten, Ausnahme bei Neubauten, dort zeichne ich 
> üblicherweise den Umriss komplett neu. (Natürlich geht auch mal eine Historie 
> verloren, das ist aber die Ausnahme).
> Warum ich aktuell in Salzburg hängen geblieben ist, ist einfach erklärt, 
> es macht dort einfach großen Spaß zu mappen, da hier so vieles zu tun ist. 
> Gewaltig ist natürlich wenn man mal einen verstohlenen Blick rüber zur Google 
> 3D Ansicht macht. Abzeichnen geht natürlich nicht,  Da kommen einem aber 
> schon Zweifel ob OpenStreetMap noch Sinn macht. Die Google 3D Ansicht ist 
> aber genauso überfrachtet wie die von Negreheb neuerdings probierten 
> Farbklecks https://www.openstreetmap.org/#map=19/47.82509/13.05223
> Ich finde eine klare auf das wesentliche reduzierte Ansicht, liefert 
> einen tatsächlichen Mehrwert, welche dann auch gegenüber der Google Standard 
> Ansicht, und der Basemap sowieso besteht. 
> https://www.openstreetmap.org/#map=18/47.66050/12.38641
> 
> Grüße Johann
> 
> 
> > > (was ich wohl auch in den seltensten Fällen besser hinbekomme als
> > ein automatischer Algorithmus, weil man ja von oben nicht sieht, 
> > was unter
> > dem Dach ist) oder eben gerade aus einer behördlichen OGD-Karte wie 
> > der
> > Basemap oder der Mehrzweckkarte (MZK) der Stadt Wien. 
> > (Normalerweise mache
> > ich letzteres, denn da muß ich nicht selbst die Kanten suchen, 
> > sondern
> > jemand, egal ob Mensch oder Algorithmus, hat die Arbeit schon für 
> > mich
> > erledigt.)
> > 
> > Kevin Kofler
> > 
> > 
> > ___
> > Talk-at mailing list
> > Talk-at@openstreetmap.org mailto:Talk-at@openstreetmap.org
> > 

Re: [Talk-hr] Import ZET ID-ova od stanica iz GTFS-a

2020-12-17 Diskussionsfäden Janko Mihelić
Evo, dio importa je završen, tu su changesetovi:
https://wiki.openstreetmap.org/wiki/Zagreb/Import_ZET_GTFS#Workflow

Sigurno nije savršeno točan, problemi su nastajali kod autobusnih okretišta
gdje ima gomila stanica po peronima, i onda još stanice tramvaja, i pokoja
autobusna stanica koja je blizu ali nije dio okretišta. Te djelove ćemo
morati ručno popraviti kad vidimo koji gtfs:stop_id se odnosi na što.

U ovom koraku sam spajao stanice koje imaju isto prvo slovo u imenu
stanice. Slijedeći korak je spojiti stanice koje u OSM-u možda nemaju
imena, ili ih uopće nema ucrtano. To bi možda napravio na malo drugačiji
način, tako da ih uvezem sa fixme=import_zet tagom, i onda na Maproulette-u
te stanice popravimo, stavimo na pravo mjesto uz cestu, poduplamo ako
postoji stanica na obje strane ceste, i slično.

Janko

sub, 5. pro 2020. u 16:52 Janko Mihelić  napisao je:

> On Sat, Dec 5, 2020, 16:25 Ivan Habunek  wrote:
>
>> Je li gtfs:stop_id:ref nužan za import? Čini mi se da nam inače taj tag
>> nije potreban, ili barem ne znam za što bi se koristio. Ako je nužan,
>> možda bi ga mogli obrisati nakon što import završi?
>>
>
> Nije nužan ni za import. Imao sam osjećaj da bi možda olakšao daljnje
> održavanje importa, ali zapravo, sad kad gledam, bolje da ga ne uvodimo.
>
> Gledam wiki gdje na Buses stranici [1] predlažu da se broj perona
>> unutar stanice obilježava `local_ref` tagom, dok na dokumentaciji tog
>> taga [2] kaže da je češća praksa da se koristi samo `ref`.
>>
>
> E to bi mogli početi koristiti. Možda radije local_ref jer su manje šanse
> da će netko imati drugu ideju za što služi ref tag. Ali to nema veze sa
> importom ako odustanemo od dodavanja toga. Evo, budem obrisao taj tag sa
> wikija.
>
> Janko
>
___
Talk-hr mailing list
Talk-hr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-hr


[Talk-GB] MapThePaths downtime

2020-12-17 Diskussionsfäden Nick Whitelegg via Talk-GB
Hello everyone,

I have updated mapthepaths.org.uk's DNS record to point to a different server. 
When this is done I will need to obtain a new HTTPS certificate. It's possible 
that interruptions may occur over the next 24 hours or so but once updated it 
will be up without further interuption.

Thanks,
Nick


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-at] OSM Gebäude, Dachfläche oder Grundriss

2020-12-17 Diskussionsfäden Stefan Tauner
On Thu, 17 Dec 2020 10:14:39 +0100
Johann Haag  wrote:

> Wie man an meiner Chronik sieht, bemühe ich mich jeweils sehr die Edit-
> Historie eines Objektes zu erhalten, Ausnahme bei Neubauten, dort zeichne
> ich üblicherweise den Umriss komplett neu. (Natürlich geht auch mal eine
> Historie verloren, das ist aber die Ausnahme).

Das Gegenteil ist der Fall. Mir ist noch nie jemand untergekommen, der
so viel nutzlos löscht und neu erstellt und die History damit zerstört.
Eine der vielen Eigenschaften deiner Edits, die sich langfristig äußerst
negativ auf OSM auswirken.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at


Re: [Talk-at] OSM Gebäude, Dachfläche oder Grundriss

2020-12-17 Diskussionsfäden Johann Haag
Am Do., 17. Dez. 2020 um 00:21 Uhr schrieb Kevin Kofler via Talk-at <
talk-at@openstreetmap.org>:

> Johann Haag wrote:
> > Meine Frage: warum übernehmen für Gebäude die starre maschinenbedingte
> > Vorgangsweise der Basemap, nachdem wir in OSM ja frei in unserer Wahl
> > wären, und auch OSM Wiki, klar das Zeichnen des Gebäude
> > Grundrisses empfiehlt.
>
> Und wie ermittelst du eben jenen Gebäude-Grundriß? Wenn ich Gebäude
> einzeichne, kann ich sie auch nur entweder aus einem Luftbild/Orthofoto
> abzeichnen


Ich habe ein paar Beispiel Changesets erzeugt wo man sieht wie ich über die
Garagenzufahrt jeweils auf den Gebäudegrundriss schließe.
95962680
95960289
95958904
95957407
95956524
95956392
Neben der Garagenzufahrt eignen sich als weiteres Indiz der jeweilige
Gebäudeanschluss zu Nebengebäuden. Zieht man den regional üblicherweise
bekannten Typischen Dachüberstand ab, so gelingen solche Anschlüsse auch
ohne künstliche Erker oder andere Verrenkungen.
Wie man an meiner Chronik sieht, bemühe ich mich jeweils sehr die Edit-
Historie eines Objektes zu erhalten, Ausnahme bei Neubauten, dort zeichne
ich üblicherweise den Umriss komplett neu. (Natürlich geht auch mal eine
Historie verloren, das ist aber die Ausnahme).
Warum ich aktuell in Salzburg hängen geblieben ist, ist einfach erklärt, es
macht dort einfach großen Spaß zu mappen, da hier so vieles zu tun ist.
Gewaltig ist natürlich wenn man mal einen verstohlenen Blick rüber zur
Google 3D Ansicht macht. Abzeichnen geht natürlich nicht,  Da kommen einem
aber schon Zweifel ob OpenStreetMap noch Sinn macht. Die Google 3D Ansicht
ist aber genauso überfrachtet wie die von Negreheb neuerdings probierten
Farbklecks https://www.openstreetmap.org/#map=19/47.82509/13.05223
Ich finde eine klare auf das wesentliche reduzierte Ansicht, liefert einen
tatsächlichen Mehrwert, welche dann auch gegenüber der Google Standard
Ansicht, und der Basemap sowieso besteht.
https://www.openstreetmap.org/#map=18/47.66050/12.38641

Grüße Johann

(was ich wohl auch in den seltensten Fällen besser hinbekomme als
> ein automatischer Algorithmus, weil man ja von oben nicht sieht, was unter
> dem Dach ist) oder eben gerade aus einer behördlichen OGD-Karte wie der
> Basemap oder der Mehrzweckkarte (MZK) der Stadt Wien. (Normalerweise mache
> ich letzteres, denn da muß ich nicht selbst die Kanten suchen, sondern
> jemand, egal ob Mensch oder Algorithmus, hat die Arbeit schon für mich
> erledigt.)
>
> Kevin Kofler
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>


-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at


Re: [OSM-talk-fr] un début de OSM - mon commerce

2020-12-17 Diskussionsfäden Marc_marc
Bonjour,

Le 14.12.20 à 18:13, Yves P. a écrit :
>> puis-je suggérer d'améliorer les outils existant (par ex OsmMyBiz) au lieu 
>> de refaire une nouvelle rue depuis zéro ?

> on peut rajouter une entreprise, mais pas mettre à jour les informations 
> existantes

test effectué ce matin :
clic sur un commerce existant
bouton modifier :-)

je pense qu'avant de coder, il serait utile de reprendre l'inventaire
de ce qui manquent aux outils existant.
et surtout voir ce que font les outils existant, cela vous évitera de
coder un nouvel outil parce que la fonction xyz manque...
alors qu'il existe

Cordialement,
Marc



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] un début de OSM - mon commerce

2020-12-17 Diskussionsfäden Stéphane Péneau

Le 17/12/2020 à 05:12, Francois Gouget a écrit :

On Wed, 16 Dec 2020, Florian LAINEZ wrote:


Bonjour François,
Il existe une bonne raison pour laquelle aucun outil n'existe aujourd'hui
pour mettre à jour les données sur tous ces sites en une seule fois.
Il est possible d'élaborer longuement sur le sujet mais pour faire court :
la licence OdbL a été créée pour protéger le projet OSM des prédateurs qui
pourraient être tentés de piller les données sans reverser en retour.

C'est pour cela que je ne propose pas de prendre les données OSM pour
les mettre sur les autres sites mais de mettre *uniquement* les données
d'horaire etc dans une base de données séparée sous une license plus
permissive et qui servira à alimenter, entre autres, OSM.

*KO* : Commerçants -> OSM -> "Site horaires" -> Google, Pages Jaunes, etc.
*OK* : Commerçants -> "Site horaires"-> OSM, Google, Pages Jaunes, etc.

Donc pas de problème de license.


Autre solution intermédiaire :

Afficher les horaires des différents services (Osm, google, pages 
jaunes, etc...). C'est probable que ça intéresse les commerçants de 
vérifier depuis une seule page que tout est à jour. Et dans un premier 
temps, depuis ce site il ne sera possible que de modifier les horaires Osm.



Stf


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] un début de OSM - mon commerce

2020-12-17 Diskussionsfäden Jacques Lavignotte



Le 17/12/2020 à 05:12, Francois Gouget a écrit :


d'horaire etc dans une base de données séparée sous une license plus
permissive et qui servira à alimenter, entre autres, OSM.


C'est le principe même du blanchiment d'argent ;)

J.


--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] un début de OSM - mon commerce

2020-12-17 Diskussionsfäden Baptiste Lemoine - Cipher Bliss
Hello tout le monde, simple rappel que la réunion va commencer à 10h.
https://meet.jit.si/monCommerceOSM
et un petit pad de réunion
https://mypads.framapad.org/mypads/?/mypads/group/osm-hw1tz77wu/pad/view/reunion-osm-mon-commerce-jeu-17-dec-2020-ne1u077kg

Baptiste LEMOINE - Dirigeant de Cipher Bliss.com ,
---

Tel 0185461173  / Signal 0627130837 , Telegram: Tykayn , Mastodon: @tykayn, 
Riot: @tykaynchu:matrix.org N° SIRET: 79942416300035 GPG: 64A8 9B18 65E6 6523 
FD86 7CB5 8796 1FCA F978 54FF clé Duniter / Ğ1: 
8c4mVVPAHd4yLYcxWM4U8Z3zUb4WpRX1iGtX5T7tbEFE - tykayn

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

Le jeudi 17 décembre 2020 à 06:54, Vincent Bergeot  a 
écrit :

> Le 14/12/2020 à 19:07, Christian Quest via Talk-fr a écrit :
> 

> > Le 14/12/2020 à 18:13, Yves P. a écrit :
> > 

> > > > puis-je suggérer d'améliorer les outils existant (par ex OsmMyBiz)
> > > > 

> > > > au lieu de refaire une nouvelle rue depuis zéro ?
> > > > 

> > > > Si possible oui.
> > > 

> > > > Je suis un peu dépité quand je renseigne osm a un commerçant de
> > > > 

> > > > devoir lui renseigner 3 roues incomplètes au lieu d'un écosystème
> > > > 

> > > > intégré.
> > > > 

> > > > C'est bien le problème§me, il n'y a rien d'adapté pour la France et
> > > > 

> > > > de complet (par exemple on peut rajouter une entreprise, mais pas
> > > > 

> > > > mettre à jour les informations existantes).
> > > 

> > > > la liste de souhait a été évoqué ici et sur là ml aussi cette année
> > > > 

> > > > As-tu des liens stp ?
> > 

> > Améliorer les outils existants est une piste dont on a discuté, mais
> > 

> > l'idée est d'aller plus loin que ces outils d'édition génériques et de
> > 

> > s'appuyer sur les données opendata, pour limiter le plus possible les
> > 

> > infos à saisir.
> > 

> > Donc c'est du cousu main dépendant de données provenant de SIRENE ou
> > 

> > du RNM (Registre des Métiers, pour les artisans).
> 

> pour l'avoir redécouvert il y a peu, il y a ce rendu "qa" qui reprend
> 

> des analyses osmose et un code couleur de "complétude" vert ok, orange
> 

> manque, rouge peut vraiment mieux faire, bleu absent d'osm :
> 

> https://www.caresteouvert.fr/qa#16.02/44.838153/-0.598528
> 

> il y a un bug, le qa de l'url disparaît  à chaque fois mais cela
> 

> fonctionne en rajoutant ce qa.
> 

> Je ne parle pas ici nouvel outil, ancien outil, améliorer l'existant,
> 

> repartir de zéro mais fonctionnalité permettant de croiser le "meilleur"
> 

> des bases.
> 

> à plus
> 

> --
> 

> Vincent Bergeot
> 

> Talk-fr mailing list
> 

> Talk-fr@openstreetmap.org
> 

> https://lists.openstreetmap.org/listinfo/talk-fr

signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr