date:20180105

Il y a déjà de bons sites pour expliquer les règles compliquées des
adresses et surtout pour liste des fausses règles contredites par la
réalité.

Cela a été fait en anglais d'abord car on a presque tous les cas compliqués
au Royaume-Uni et toutes les exceptions. Un de ces auteurs est a été
fondateur d'OSM, avant d'aller chez MapBox. Un autre fondateur est allé
chez Mapzen (qui va fermer à la fin de ce mois-ci son service en ligne et
vient de publier ses codes sources et documentations sur GitHub, après
l'arrêt des financement de Samsung, et demande de changer de prestataire et
en propose quelques un).

La France à côté a des règles bien plus simples et moins d'exceptions (sauf
peut-être encore à Mayotte ou dans les COM du Pacifique).

Ils relèvent cependant le fait :
- qu'on écrit nos adresses avec le numéro de rue avant le nom (inverse de
l'usage anglophone le plus courant), et qu'on a aussi des cas de
numérotation continue (pas de coté pair ou impair),
- ont écrit nos code postaux avant le nom de commune de distribution
- que le nom de commune de distribution n'est pas forcément le nom de
commune du lieu (c'est le cas des bourgs décentrée ayant leur propre nom,
c'est aussi le cas des anciennes communes et des adresses proches de la
frontalière de deux communes, formant une même tournée de
distribution/livraison/collecte).
- des rues ayant deux noms (suivant le côté)
- des numérotations aussi par bloc/secteur et non par rue, les blocs
n'ayant pas toujours un nom non plus, de même les rues ne sont toujours
nommées mais ont des numéros de référence, cas fréquent dans pas mal de
villes d'Afrique (ou des noms indicatifs descriptifs tels que "chemin rural
de la VC 10 à la RN 115", cas encore plus fréquent, et dans ce cas souvent
pas de numéros visibles, juste des distances de parcours mais dans les
fichiers uniquement un numéro calculé le long d'un parcours piéton en bord
de chaussée ou d'allée piétonne, avec main droite pointant vers l'adresse
et main gauche vers le centre de la chaussée ou allée).
- des séquences discontinues
- plusieurs batiments formant pourtant des résidences séparées mais portant
le même numéro (sans nécessairement avoir des bis/ter/...
- la situation inverse aussi avec plusieurs pour le mêm batiment
- des numérotations suivant le niveau/l'étage (et des nom de rues
superposées par endroit)
- des noms de "sous-rues" à l'intérieur d'une rue de même nom
- des rues continues passant plusieurs fois d'une commune à l'autre sans
interrompre la numérotation ni posssiblité de distinguier pair/impair, ou
au contraire des sequences de numéros distinctres selon la commune (avec
donc des doublons apparent de numéros dans ce qui semblerait être la même
rue sans carrefour intermédiaire)

On n'est pas aussi clean que le Japon qui suit une logique assez précise de
hiérarchisation des blocs sans utiliser des noms de rues mais qui a aussi
des exceptions, et en tout cas pas non plus comme en Afrique centrale, en
Asie du Sud ou en Amérique centrale où rien n'est "logique" et standard.

Le 5 janvier 2018 à 14:20, althio  a écrit :

> Il me semble que l'auteur de StreetComplete (application Android de
> collecte et contribution) aurait besoin d'information sur les
> pratiques "adresses" en France... de manière à décider si son
> application devrait ou ne devrait pas proposer des modifications
> concernant les adresses en France.
>
> Voir (et intervenir ?) sur
> https://github.com/westnordost/StreetComplete/issues/714#issuecomment-
> 353980856
>
> Vos avis ?
>
> -- althio
>
>
> 2018-01-05 14:04 GMT+01:00 Christian Quest :
> > Marc, tu te trompe sur plusieurs points.
> >
> > contact:* est documenté et l'était bien avant qu'on en parle ici. Il
> s'agit
> > bien d'indiquer pour un POI le moyen de le contacter, pas que via son
> > adresse. Séparer la définition de l'adresse et celle du POI est assez
> > logique.
> >
> > Les deux schémas utilisé pour modéliser les adresses sont largement
> > utilisables, que ce soit avec les relations ou sans.
> >
> > On peut tout à fait relancer la discussion, mais comme les éléments de
> > départs n'ont pas changé, je ne vois pas pourquoi on arriverait à une
> autre
> > conclusion.
> >
> >
> > Il ne faut pas tout mélanger. Là, le départ c'est une anomalie signalée à
> > juste titre par osmose (si j'ai bien suivi) avec des modifications
> faites à
> > moitié.
> >
> >
> > Les adresses ça semble simple, mais en même temps c'est complexe, ce que
> > j'ai découvert en bossant ces dernières années sur le sujet. Pour
> beaucoup
> > de monde il y a confusion entre adresse et bâtiment (d'où cette tendance
> à
> > mettre des adresses sur les polygones de bâtiments) alors que non, ça
> n'est
> > pas du 1 vers 1.
> >
> > J'ai encore dû expliquer à un dev ce matin qui réalisait un écran de
> saisie
> > d'adresse sur une borne que non, les codes postaux ne correspondent pas à
> > une commune... qu'il y a environ 6000 codes postaux et plus de

Re: [OSM-talk-fr] maxspeed:type vs source:maxspeed

Le 5 janvier 2018 à 20:43, Rodrigo Vivar  a écrit :

> Le 30/12/2017 à 13:17, marc marc - marc_marc_...@hotmail.com a écrit :
> > Bonjour,
> >
> > Le 30. 12. 17 à 13:01, Rodrigo Vivar a écrit :
> >> - 5 395 "maxspeed:type"
> >> - 63 480 "source:maxspeed"
> >> wiki dit "maxspeed:type" en GB et "source:maxspeed" reste du monde
> >> Regardant des "maxspeed:type" trouvés en France, vois "created_by
> >> StreetComplete 2.3"
> >> ca est un effet du brexit ?
> > source:maxspeed est une aberration historique (cela entre en conflit
> > avec source:maxspeed=survey ou opendata ou mapillary ou jenesaisquoi)
>
> Ne comprends pas pourquoi "source:maxspeed=sign" en conflit avec
> "source:maxspeed=survey" si je écris "maxspeed=70" + "source:maxspeed=sign"?
>

- "maxspeed=70" + "source:maxspeed=sign" indique juste qu'il est supposé y
avoir un panneau de limitation à 70 à cet endroit, cela n'indique pas
l'origine de l'information et en tout cas ps si cela vient d'un relevé de
terrain.
- "maxspeed=70" + "source:maxspeed=survey" indique qu'un relevé de terrain
indique une limitation à 70 à et endroit, mais cela n'indique pas comment
elle est indiquée ni que cela a été vu sur un panneau. Ce peut être la
compréhension du lieu, ou une réglementation locale connue par celui qui
est allé sur le terrain ou qui peut être visible ailleurs (à l'entrée de la
commune par exemple pour modifier le sens normal de limitation par défaut à
50 à l'entrée d'une agglomération)

Bref on ne peut pas combiner les deux.

La solution serait"source:maxspeed=survey;sign" mais on préfère garder
"source:maxspeed=survey/knowledge/opendataXXX..."
(origine de la donnée), et séparer "maxspeed:type"="sign/urban/rural/"
(où on peut aussi distinguer des cas sur le type et la validité de la
signalisation jusqu'au carrefour suivant ou jusqu'à un signal de fin de
limitation).

Note : la valeur "sign" n'est pas forcément un panneau, c'est n'importe
quel type de signalisation.
Ce peut être un signal au sol, un feu... Il peut être peint, lumineux (fixe
ou clignotant), ou à blocs colorés mobiles, statique ou dynamique, il peut
alterner avec le signal du feu rouge imposant l'arrêt ou un signal orange
de danger prévenant qu'il va falloir s'arrêter, il peut être couplé à un
radar de mesure, l'affichage alternant entre la vitesse maxi autorisée et
la vitesse mesurée.
Il peut être là à certaines heures et pas d'autres (en présence d'un agent
de circulation qui peut aussi restreindre la vitesse davantage en portant
un panneau mobile qu'il peut retourner pour montrer en panneau stop). Il
peut s'appliquer quand une barrière est ouverte et changer quand la
barrière est fermée et impose un contrôle ou le passage d'un péage. Il peut
être conditionné à d'autres éléments changeants (exemple présence de trop
fort vent, indiqué par une autre signal qui vient le contredire en étant
mis davantage en valeur par un signal clignotant placé à côté ou en le
plaçant juste 1 ou 2 mètres derrière ou au dessus de la chaussée. Si deux
limitations de vitesse ne sont pas éloignées de plus de 50 mètres (en
ville) c'est la seconde indication qui s'applique dès qu'on la voit (c'est
comme s'il n'y avait qu'un seul panneau, le plus limitatif
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-it] Ris: appostamenti di caccia non attivi

2018-01-05 Per discussione beppebo...@libero.it

Difficile sapere se in capanno di caccia si spara o no i cacciatori vanno a sparare negli orari più impensabili e cambiano di continuo per cui lo possono usare anche solo 1 volta in stagione. Ad esempio qui da me disturbano dalle 5 del mattino e li sento ma due colline dopo no sembra tutto abbandonato ma se si osserva bene qualche pallino lo si trova per cui io il disused non lo userei a meno che il capanno non sia evidentemente messo male e devastato ma anche in quel caso ci vorrebbe Magnum pi o Colombo. Messaggio originale Oggetto: [Talk-it] appostamenti di caccia non attiviDa: "demon.box" A: talk-it@openstreetmap.orgCC: mi capita ormai sempre più spesso di trovare appostamenti di caccia nonabbandonati ma palesemente non attivi.ora il wiki per amenity=hunting_standhttps://wiki.openstreetmap.org/wiki/Tag%3Aamenity%3Dhunting_standammette questo tag soltanto per un nodo.vista la fresca discussione sul prefisso disused: sarebbe opportuno marcarlicomedisused:amenity=hunting_standma così facendo sparisce tutto mentre di fatto il capanno esiste ancorasoltanto che non si spara più, come lo risolvo?definire il capanno di caccia un building (sono perfettamente d'accordo conil wiki) mi sembra in effetti eccessivo...l'unica soluzione che mi viene ancora in mente è (e forse questa è proprioun'eccezione alla regola):amenity=hunting_standdisused=yescosa ne pensate?oppure pensate sia giusto che dalle mappe sparisca tutto?per chi mastica di sentieri escursionistici vorrei ricordare quante voltenelle descrizioni si citano come punto di riferimento capanni di caccia nonattivi oppure addirittura abbandonati... a mio parere è giusto che qualcosavenga comunuque renderizzato.grazie--enrico--Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html___Talk-it mailing listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] appostamenti di caccia non attivi

mi capita ormai sempre più spesso di trovare appostamenti di caccia non
abbandonati ma palesemente non attivi.

ora il wiki per amenity=hunting_stand

https://wiki.openstreetmap.org/wiki/Tag%3Aamenity%3Dhunting_stand

ammette questo tag soltanto per un nodo.

vista la fresca discussione sul prefisso disused: sarebbe opportuno marcarli
come

disused:amenity=hunting_stand

ma così facendo sparisce tutto mentre di fatto il capanno esiste ancora
soltanto che non si spara più, come lo risolvo?

definire il capanno di caccia un building (sono perfettamente d'accordo con
il wiki) mi sembra in effetti eccessivo...

l'unica soluzione che mi viene ancora in mente è (e forse questa è proprio
un'eccezione alla regola):

amenity=hunting_stand
disused=yes

cosa ne pensate?
oppure pensate sia giusto che dalle mappe sparisca tutto?

per chi mastica di sentieri escursionistici vorrei ricordare quante volte
nelle descrizioni si citano come punto di riferimento capanni di caccia non
attivi oppure addirittura abbandonati... a mio parere è giusto che qualcosa
venga comunuque renderizzato.
grazie
--enrico





--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-cz] petr1868: data znicena LPIS importem na Zernovce

2018-01-05 Per discussione Marián Kyral


-- Původní e-mail --
Od: Pavel Machek 
Komu: OpenStreetMap Czech Republic 
Datum: 5. 1. 2018 18:22:45
Předmět: Re: [Talk-cz] petr1868: data znicena LPIS importem na Zernovce
"Ahoj!

> "Ahoj!
>
> Preplacnout LPISem existujici data neni vzdy dobry napad. Viz nesmysl 
> ktery vznikl na
>
> http://www.openstreetmap.org/#map=19/50.00352/14.74784
>
> Autora muzu ujistit ze takhle to tam opravdu nevypada, kdyby to
> nahodou nebylo jasne; puvodni data odpovidala.
> "
>
>
>
> Tady bych to viděl na nějaký bordel v LPIS:
>
> https://openstreetmap.cz/#map=18/50.00380/14.74698=oONL
>
>
>
>
> Pravděpodobně se snaží získat dotace na co největší zatravněnou plochu.
> Takže místa, kde je jen hlína zahrnuta nejsou. Ale proč je z toho v LPISu
> orná půda fakt netuším.
>
>
> "
>
>
>
> Hmm,
>
>
> landuse=farmland, crop=grass

No problem hlavne je nekdo (petr1868) prevzal cast puvodniho znaceni
-- barrier=fence. A muzu svet ujistit, ze plot nenasleduje hranici
hlina -- trava :-).
"



No třeba to příště udělá líp ;-)



"
To znaceni landuse=farmland, crop=grass taky neodpovida, je to louka 
na ktery jsou kone, ne pole na kterym se pestuje trava...
"



Hele, já to nebyl, kdo to v LPISu označil jako "Tráva na orné". Na to
tagování přesně sedí :-D





https://github.com/mkyral/josm-tracer/blob/development/src/org/
openstreetmap/josm/plugins/tracer/modules/lpis/LpisRecord.java#L121




Marián



"Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/
blog.html
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
"___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Novy kruhac v Brne

2018-01-05 Per discussione Michal Pustějovský


Ahoj,

Já bych na vícepruhovém kruhovém objezdu odbočovací pruhy vyznačil. 
Situaci na místě neznám, ale při koukání na zastaralé ortofoto to 
například při příjezdu ze Sportovní vypadá, že je odbočení vpravo směr 
Husovice povoleno jen z pravého pruhu. Samo, situace teď může být úplně 
jiná.


Tvá varianta značení sedí na popisovanou situaci. Jestli používáš JOSM 
doporučuju si zapnout styl kreslení mapy "Lanes and road attributes" 
. 
Ten mimo jiné zviditelňuje počty pruhů / odbočovací pruhy.


Michal

Dne 05.01.2018 v 21:13 Karel Volný napsal(a):

pro zajímavost [...], dneska ráno jsem tam jel

za tohle by se projektanti měli pro výstrahu věšet na šibenici uprostřed

nicméně nerozumím, co by mělo být potřeba s tím mapováním odbočovacích pruhů?

pokud mi to utkvělo v hlavě správně (sledoval jsem více provoz než vodorovné
značení, a za třináct hodin paměť docela vyprchá), tak na tom novém úseku

http://www.openstreetmap.org/way/164599152

se odbočuje z obou (viz výše o šibenici)

což by se asi psalo takto:

turn:lanes=through;right|through;right

což je asi zbytečné, neb to nevyjadřuje žádné omezení možnosti (ne)odbočit

...?

K.

Dne pátek 5. ledna 2018 17:55:09 CET, Michal Pustějovský napsal(a):

Ahoj,

Koukal jsem na to a je to v pořádku. Chybělo pouze přidat dva úseky
kruháče do relace silnice I/43, ale to je drobnost. Pěkná práce! Pokud
by ses v okolí vyskytoval častěji, možná by stálo za to zmapovat
odbočovací pruhy.

Michal

Dne 05.01.2018 v 15:56 Jakub Jelen napsal(a):

Pro zajimavost, dnes jsem si vsiml, ze uz je i v google mapach.
Mapy.cz jsou stale pozadu.

Dnesni nahled na porovnani mapy:




2017-12-24 23:50 GMT+01:00 Jakub Jelen >:
 Zdravim,
 
 pred par dny nam prestaveli silnici v Brne na kruhac a tak jsem se

 odhodlal k trochu "vetsi" uprave v OSM, aby mapa odpovidala realite. A
 protoze jsem prece jenom stale zacatecnik (uz nekolik let), tak
 bych si
 rad vyslech vyhrady ke zmene, co jsem zapomnel, co slo udelat lepe
 a to
 radeji takto s primym odkazem na chcangeset (nize), nez aby to nekdo
 pozdeji omylem nasel a divil se proc neco nefunguje.
 
 Zaklad kruhu uz byl na miste jako "construction" a tak jsem jej

 vyuzil.
 Stejne tak jsem preroutoval relaci, ktera vedla puvodni rovnou silnici
 (stejne mam pocit, ze je rozbita na jinych mistech) a zmenil puvodni
 juncion=circular na roundabout, protoze tam mame konecne tyto znacky.
 
 Mapoval jsem pouze pomoci nocnich fotek (nezaostrene) a jejich GPS

 pozice z Mapillary. Ani na fotomapach, ani v katastru to jeste neni.
 
 Budu rad za kazde rady a tipy.
 
 http://overpass-api.de/achavi/?changeset=54897143

 
 http://www.openstreetmap.org/changeset/54897143#map=17/49.21855/16.602
 05
 
 
 Diky,
 
 Jakub


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




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



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

Re: [Talk-cz] petr1868: data znicena LPIS importem na Zernovce

2018-01-05 Per discussione Marián Kyral


-- Původní e-mail --
Od: Pavel Machek 
Komu: OpenStreetMap Czech Republic 
Datum: 5. 1. 2018 18:29:00
Předmět: Re: [Talk-cz] petr1868: data znicena LPIS importem na Zernovce
"On Fri 2018-01-05 15:55:39, Zdeněk Pražák wrote:
> no pokud to mohu posoudit podle IPR Ortofota tak jsem to opravil

No, dekuju. Smazu zbyvajici nudle, a pridam zpet ploty kde maji byt.

Myslim ze tam byval zmapovany pristresek, ten zda-se nekdo smazal. Dam
ho zpet.

Jen uvazuju co s tema lpis tagama. Smazat? Nechat? Zatim sem je
nechal.
Pavel
"



Ono to je jedno. Klidně to smaž, moc to těm datům v lpis už neodpovídá ;-)




Btw, co ten "seník". To je nějaký historický objekt? Pokud ne, nemáme na to
nějaký tag?




A co ten travnatý pás uprostřed? Dá tam někdo trávu? A co tam ten "dvůr"? Já
bych to zmapoval jako normální zemědělský dvůr statek - farmyard nebo jak to
je.





Marián



"
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/
blog.html
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
"___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-fr] Contours des IRIS

Le 4 janvier 2018 à 17:34, marc marc  a écrit :

> Le 04. 01. 18 à 15:00, Philippe Verdy a écrit :
>
> Une première étape utile serrait donc d'avoir cette version partiellement
> intégrée à jour.


Certainement pas ! OSM ne fonctionne pas avec des imports même à jour mais
"partiellement intégré" ce n'est pas du tout admis et c'est même interdit
les règles de base d'OSM.
Si on veut un rendu à jour (et non intégré) il suffit d'afficher une couche
séparée sur un rendu séparé, et là on a déjà toutes les données dans les
fichiers SHAPES fournis par l'INSEE cela ne demande aucun travail de
préparation et cela ne répond pas au problème du tout.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Contours des IRIS

On n'a pas fait comme ça du tout pour les communes ou les cantons :
l'automatisme est en fait plus que douteux pour ce genre de projet sachant
qu'on a des imprécisions évidentes et un gros travail de conflation à faire
pour recoller à l'existant. Alors non je n'ai jamais parlé d'import mais
bien d'intégration

Les données de l'Insee seront là juste à titre de comparaison pour fire du
rapprochement et juger de la qualité relative finale

Mais évidemment pour faciliter ces rapprochements les identifiants de
référence Insee doivent être intégrés (ref:FR:INSEE=*, seulement si on veut
éviter la confusion avec les codes INSEE communaux actuellement dans
ref:INSEE, à moins que le format des codes IRIS reprenne le format du code
INSEE communal et qu'on ne code le numéro d'IRIS de la commune après, mais
pas isolément ; cependant on risque d'avoir Osmose trouvant étrange ces
codes INSEE "communaux", et il vaut peut-être mieux utiliser un séparateur
"-" entre les deux et non pas ":" discuté déjà pour le versionnement avec
des dates; toutefois cette référence porte sur des objets frontière qui ne
sont pas de même type et qu'on ne peut pas confondre).

De plus je ne demande absolument pas qu'on y ajoute des "admin_centre"
(aucun sens ici) ni même des noeuds  membres "label"  inutile. En effet,
même si de nombreux IRIS ont des noms qu'on peut indiquer dans leurs
relation avec "name=*" et qu'on n'a pas besoin de traduire, il n'est pas
nécessaire cependant d'afficher des noms d'IRIS sur les rendus carto, ce
nom n'apparaitra utile que sur des interrogations de données de la carte
sur un point ou une frontière sélectionnée; puisque ce nom ne devrait pas
être visible sur un rendo carto, on ne //devrait// pas avoir besoin
d'indiquer un placement avec un noeud "label" (qui n'est de toute façon
utile QUE pour ses coordonnées suggérées, et jamais pour son/ses noms
contenus dans le noeud) ; cependant rien ne devrait l'empêcher si ça
facilité l'usage, seul "admin_centre" ne devrait pas être utilisé du tout
(ce n'est pas une frontière administrative, juste une frontière
statistique). Ces noeuds cependant ne devrait pas être créés exprès, on ne
devrait prendre que les noeuds place=* existants s'il correspondent
correctement par leur nom actuel et sont bien dans la surface, sinon ils
seront plus une pollution inutile (i on choisit un noeud place, il ne faut
PAS en changer le nom même s'il est un peu différent du nom de l'IRIS

(d'ailleurs la remarque s'applique également aux noeuds "place=*" utilisés
en  "admin_centre" des communes qui ne devraient JAMAIS non plus être
modifié pour correspondre au nom de la relation pour la collectivité
communale (et surtout pas si c'est une "commune nouvelle", la toponymie
fine des "place=*" n'a rien à voir avec les noms des entités ou
collectivités administratives qui les contient et c'est suffisant de nommer
ces entités dans leur relation et pour placer un label, avec ou sans icone,
si on n'affiche pas le nom le long des frontières).

Et de toute façon hors de question d'automatiser un import sans avoir fait
un essai manuel avant. Je ne pense même pas que l'uatomatisation soit
nécessaire (tout ce qu'on peut avoir besoin éventuellement c'est un tableau
d'avancement, mais on n'a pas forcément besoin d'un outil pour ça, c'est
facile d'en créer un sur le wiki (une page par département, certains
départements seront vite traités, on n'est pas obligé de commencer par les
mettre tous. Et ce sera nettement plus facile à faire et moins long que les
cantons qui nous a posé des tas de soucis pour interprêter les arrêtés et
rechercher les rues mais qui déjà nous donne aussi de bonnes indications
(avec les autres frontières administratives communales, ou
d'arrondissements ou quartiers et sous-quartiers) pour recadrer les IRIS.

On peut définir une règle de conflation avec des écarts ne dépassant pas
les 20 mètres environ, sinon on reprend le tracé donné par l'Insee tel quel
(à moins que d'évidence il suivant une rue mais pas tous ses virages et
vient découper des bâtiments en deux dans des coins "riquiquis", mais on ne
devrait cependant pas avoir à coller ces traits sur le tracé des bâtiments
mais plutôt sur le tracé des parcelles cadastrales qu'on n'importera pas
non plus directement car il n'y a aucune raison qu'une commune a découpé
ses IRIS sur autre chose que les limites cadastrales de propriétés, autre
que le fait qu'une propriété a été depuis subdivisée ou des morceaux
regroupés avec d'autres voisins pour construire un même bâtiment avec une
seule adresse occupée c'est un cas où l'INSEE doit déterminer la parcelle
la plus pertinente pour centrer l'occupant dans l'IRIS, mais on n'a de
toute façon pas le détail à ce niveau parcellaire dans les statistiques,
les IRIS peuvent donc garder une certaine imprécision tant que cela ne joue
pas trop fortement sur les critères de secret statistique et de protection
des données personnelles des occupants, le minimum étant tout de même que
les occupants soient dans

Re: [Talk-it] Un problema con JOSM

2018-01-05 Per discussione Andrea Albani

Il giorno 5 gennaio 2018 22:47, Max1234Ita  ha
scritto:

> Ciao a tutti,
> oggi ho aggiornato JOSM alla versione più recente (13265): dopo aver
> modificato/aggiunto alcune way, al momento di caricare il changeset la
> validazione mi restituisce questo warning:
> "This object has no level tag, utilizzare piuttosto Delete the object or
> use
> the plug-in to add a POI tag".
>
>
Ciao, è da 4 giorni che uso questa versione, ma non ho incontrato il
problema.

Non è che nasce da un plugin che hai installato... tipo kendzi3d ? Dico
questo perchè nel forum OSM in lingua tedesca un utente si lamenta del
medesimo problema [0] e parla esplicitamente di questa estensione.

Ciao

[0] https://forum.openstreetmap.org/viewtopic.php?id=53554=5
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] chiusa su canale

Grazie ;-)

--enrico




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-it] chiusa su canale

2018-01-05 Per discussione Andrea Albani

Ciao,

lock_gate fa riferimento agli sbarramenti mobili che permettono alle barche
di superare dei dislivelli, quindi non si applica al caso.

Esiste un tag in stato draft [0] che documenta il tipo di chiuse nella foto
(in inglese sluice gate).

Viene proposto di mettere, nella forma più semplice, un nodo sulla waterway
marcato con
waterway=flow_control
flow_control=sluice_gate

da taginfo questa modalità è usata in 179 casi, mentre in altri 199 viene
usato un nodo con waterway=sluice_gate (e in altri 20 man_made=sluice_gate).

Ciao

[0] http://wiki.openstreetmap.org/wiki/Proposed_features/sluice_gate
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] chiusa su canale

2018-01-05 Per discussione liste DOT girarsi AT posteo DOT eu

ciao, scusate, come si mappa una chiusa su un canale come questa?

 

ho trovato waterway=lock_gate

https://wiki.openstreetmap.org/wiki/IT:Key:lock

ma non va bene perchè parla espressamente di chiuse di grandi dimensioni che
permettono o meno il passaggio di imbarcazioni...

voi cosa usate?

grazie.

--enrico




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-de] Kartendruck hochauflösend

2018-01-05 Per discussione nebulon42

Vielleicht hilft das: http://printmaps-osm.de:8080/
Ist nicht von mir, daher kann ich auch nicht mit Details weiterhelfen.

Michael

Am 2018-01-05 um 20:52 schrieb Markus:
> _Eilt_
> 
> Liebe OSMer,
> 
> wer kann hochauflösende Karten drucken?
> Wen köönnte ich direkt fragen?
> 
> Ein Luxus-Yachtkonstrukteur hätte gern für einen Messeauftritt zwei
> Kartenausschnitte von OpenSeaMap für Print.
> (s. Screenshot)
> 
> Darf auch angemessen kosten :-)
> Sollte möglichst am WE (Samstag) fertig sein...
> 
> z=16
> 100x50 cm
> 150 DPI
> - Basiskarte
> - Seezeichen
> - Koordinatengitter
> - Häfen
> 
> Mit herzlichem Gruss,
> Markus
> 
> PS: die zugehörigen Kartenausschnitte gibt es per PM
> (die Liste lässt keine Anhänge zu)
> 
> 
> 
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
> 



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

Re: [Talk-it] Un problema con JOSM


Il 05/01/2018 22:47, Max1234Ita ha scritto:

Ciao a tutti,
oggi ho aggiornato JOSM alla versione più recente (13265): dopo aver
modificato/aggiunto alcune way, al momento di caricare il changeset la
validazione mi restituisce questo warning:
"This object has no level tag, utilizzare piuttosto Delete the object or use
the plug-in to add a POI tag".




Ho la stessa versione, però a me va tranquillamente.

Non è che hai dei punti/way senza tag?


--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

[Talk-it] Un problema con JOSM

2018-01-05 Per discussione Max1234Ita

Ciao a tutti,
oggi ho aggiornato JOSM alla versione più recente (13265): dopo aver
modificato/aggiunto alcune way, al momento di caricare il changeset la
validazione mi restituisce questo warning:
"This object has no level tag, utilizzare piuttosto Delete the object or use
the plug-in to add a POI tag".



Questo viene visualizzato indipendentemente dall'oggetto che vado a taggare,
sia esso un vialetto di accesso ad un garage (highway=service;
access_private), un filare di alberi (natural=tree_row) o una banalissima
siepe (barrier=hedge).

Mi verrebbe da pensare che sia un problema dovuto ad un qualche bug
dell'editor: se poi utilizzo la funzione di correzione automatica degli
errori di JOSM, tutti i warning vengono eliminati e l'upload va a buon fine.

Per caso capita anche a qualcun altro?

Grazie in anticipo e... buona Befana a tutti! :-)

Max



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-cz] Jednosměrka

2018-01-05 Per discussione Pavel Machek

On Fri 2018-01-05 19:58:13, Jiří Komárek wrote:
> Nejsem si 100 % jistý, ale řekl bych, že "chyba" bude v navigaci: zřejmě
> neumí navigovat podle ročních období. Dotaz bych vedl na vývojáře navigace
> (a tady si nejsem jist, zda-li budou ochotní takovouto funkcionalitu přidat.
> Přeci jen, je to dost speciální případ)

Tohle je pro navigaci... celkem problem. Predstavte si ze vyjizdite na
konci brezna...

Spousta navigaci ma predpocitana reseni (aby umeli hledat "hned" a
netrvalo to 10 sekund)... a tam ta podminena jednosmerka nejspis
nepujde rozume udelat :-(.
Pavel



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-us] Parks, again

2018-01-05 Per discussione OSM Volunteer stevea

On January 4, 2018 at 6:21:03 PM PST, Bradley White  
wrote:
>> I don't think the title
>> given to a piece of land should necessarily have bearing on the data
>> representation, in the same way "Hampstead Heath" doesn't get
>> "natural=heath" just because it's in the name.

I forgot to make this point in my previous post.  The British English 
convention of calling a (sometimes municipal) park-like area "Hampstead Heath" 
being explicitly stated as a different semantic than what OSM tags 
"natural=heath" is an important distinction to make, and I'm glad our wiki does 
so.

However, by way of contrast, something called "Park" generally IS a park:  I 
seldom, if ever, find an exception to this.  As long as that is true (and 
contrasts sharply with "heath" as you and our wiki remind us), I'll continue to 
tag something named "Park" with leisure=park.  Yes, sometimes I'll use 
leisure=nature_reserve, but guess what?  That's because it's name contains 
"Nature Reserve" or "Open Space Reserve" or some other set of English words 
that map directly onto the tag "leisure=nature_reserve."

So, while it doesn't NECESSARILY have bearing, I am an intelligent enough user 
of language (and its derived semantics) to "properly" map these semantics to 
specific syntax tags in OSM.  All OSM volunteers must do at least a little bit 
of this, and we can even talk about the more subtle aspects of doing so in a 
forum like talk-us.

Our tag of park, I continue to assert most assiduously, is vast and elastic.  
We might improve it with a rich schema, but until then, it is correct to tag 
park entries with this tag.

SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-cz] Jednosměrka

2018-01-05 Per discussione Vladimír Slávik

Ahoj, je tam

oneway=conditional=yes @ (Nov - Mar )

pokud nejsem úplně mimo, správně má být

oneway:conditional=yes @ (Nov - Mar)

Vláďa
-- Původní e-mail --
Od: Jiří Komárek 
Komu: talk-cz@openstreetmap.org
Datum: 5. 1. 2018 19:59:03
Předmět: Re: [Talk-cz] Jednosměrka
"

Nejsem si 100 % jistý, ale řekl bych, že "chyba" bude v navigaci: zřejmě
neumí navigovat podle ročních období. Dotaz bych vedl na vývojáře navigace
(a tady si nejsem jist, zda-li budou ochotní takovouto funkcionalitu přidat.
Přeci jen, je to dost speciální případ)


On 5.1.2018 19:51, marek wrote:

"
Upravil jsem ulici na jednosměrku, aby v zimních měsících byla průjezdná jen
jedním směrem, ale navigace mě stále vede oběma směry. Tak nevím kde je
chyba.

https://www.openstreetmap.org/edit#map=19/50.73378/15.18578
(https://www.openstreetmap.org/edit#map=19/50.73378/15.18578)

 

Marek Polák

 





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

"

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

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

2018-01-05 Per discussione Vincent Frison

Le 5 janvier 2018 à 20:21, Christian Quest  a
écrit :

> Pour moi c'est à éviter car ça fait dépendre ton rendu d'un service tiers
> dont on ne contrôle pas la disponibilité.
>
> Si les tuiles externes d'ombrage ou de courbe de niveau ne sont pas
> dispo... on fait quoi ?
>
> Un serveur de tuile doit fonctionner en autonomie. Sur un client, c'est
> différent, tu peux mixer les tuiles si tu veux, vu que de toute façon tu
> dépends en général de tuiles tierces.
>
> Je digresse un peu... le recours bien facile aux services et données tiers
> c'est "pratique", mais casse gueule aussi.
> Les très nombreux utilisateurs des fonds mapquest en ont fait les frais...
> ceux qui utilisent les services de mapzen vont le découvrir à la fin de
> mois (mapzen plie boutique).
>
> Comme les médocs, les API c'est bien, en abuser ça craint ;)
>

Surtout si elles sont périmées :)

D'un point de vue purement serveur c'est vrai qu'il faut éviter de dépendre
des services extérieures, et si OSM FR était capable de fournir ça tout
seul ça serait vraiment génial !

Mais d'un point de vue client ça serait quand même bien sympa d'avoir un
layer supplémentaire pour le relief sur http://tiles.openstreetmap.fr :)

En fait y a déjà l'option Hillshshade (@openskimap.org) sauf que là aucun
des couches overlays fonctionnent...

D'ailleurs c'est dommage que cette page ne soit pas facilement accessible
depuis www.openstreetmap.fr, mais peut-être est ce un choix volontaire ?

Plus globalement je trouve qu'il manque une page (voir un menu) listant
tous les super projets fait par OSM FR: osmose, les outils pour BANO ou le
cadastre, le serveur de tuile pour ne citer que ceux que je connais...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

2018-01-05 Per discussione Jean-Claude Repetto


Le 05/01/2018 à 18:59, Vincent Frison a écrit :


Donc l'idée c'est est d'avoir un MNT en local et une moulinette 
permettant de le convertir à la volée en jolis tuiles rasters avec 
transparence, puis bien configurer mapnik pour qu'il les utilise.




C'est ce que fait le site http://francetopo.fr/. Il y a trois couches:
- le fond avec les ombrages
- la cartographie (routes, noms, ...)
- les courbes de niveau.

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

Re: [Talk-de] routing.openstreetmap.de

2018-01-05 Per discussione Toni Erdmann


Danke, ist behoben.

Viele Grüße
Toni

Am 05.01.2018 um 21:28 schrieb michael spreng:

Hallo

On 31/12/17 15:05, Toni Erdmann wrote:

Ausgerechnet meine erste Route war sehr komisch.

'Bike'

von 'Rosenheimer Landstraße 44; Ottobrunn, Landkreis München, Upper
Bavaria, Bavaria, 85521, Germany'

nach 'A2J7D9, Avenue du Général de Gaulle, Pen ar Ru, Tachen An
Hospital, Lannion, Côtes-d'Armor, Brittany, Metropolitan France, 22300,
France'

aber, ja mei, warum net.


Der Bug mit den Fähren sollte nun behoben sein.

Grüsse
Michael


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

Re: [Talk-de] routing.openstreetmap.de

2018-01-05 Per discussione michael spreng

Hallo

On 31/12/17 15:05, Toni Erdmann wrote:
> Ausgerechnet meine erste Route war sehr komisch.
> 
> 'Bike'
> 
> von 'Rosenheimer Landstraße 44; Ottobrunn, Landkreis München, Upper
> Bavaria, Bavaria, 85521, Germany'
> 
> nach 'A2J7D9, Avenue du Général de Gaulle, Pen ar Ru, Tachen An
> Hospital, Lannion, Côtes-d'Armor, Brittany, Metropolitan France, 22300,
> France'
> 
> aber, ja mei, warum net.
> 
Der Bug mit den Fähren sollte nun behoben sein.

Grüsse
Michael

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

Re: [Talk-cz] Novy kruhac v Brne

2018-01-05 Per discussione Karel Volný

pro zajímavost [...], dneska ráno jsem tam jel

za tohle by se projektanti měli pro výstrahu věšet na šibenici uprostřed

nicméně nerozumím, co by mělo být potřeba s tím mapováním odbočovacích pruhů?

pokud mi to utkvělo v hlavě správně (sledoval jsem více provoz než vodorovné 
značení, a za třináct hodin paměť docela vyprchá), tak na tom novém úseku

http://www.openstreetmap.org/way/164599152

se odbočuje z obou (viz výše o šibenici)

což by se asi psalo takto:

turn:lanes=through;right|through;right

což je asi zbytečné, neb to nevyjadřuje žádné omezení možnosti (ne)odbočit

...?

K.

Dne pátek 5. ledna 2018 17:55:09 CET, Michal Pustějovský napsal(a):
> Ahoj,
> 
> Koukal jsem na to a je to v pořádku. Chybělo pouze přidat dva úseky
> kruháče do relace silnice I/43, ale to je drobnost. Pěkná práce! Pokud
> by ses v okolí vyskytoval častěji, možná by stálo za to zmapovat
> odbočovací pruhy.
> 
> Michal
> 
> Dne 05.01.2018 v 15:56 Jakub Jelen napsal(a):
> > Pro zajimavost, dnes jsem si vsiml, ze uz je i v google mapach.
> > Mapy.cz jsou stale pozadu.
> > 
> > Dnesni nahled na porovnani mapy:
> > 
> > 
> > 
> > 
> > 2017-12-24 23:50 GMT+01:00 Jakub Jelen  > 
> > >:
> > Zdravim,
> > 
> > pred par dny nam prestaveli silnici v Brne na kruhac a tak jsem se
> > odhodlal k trochu "vetsi" uprave v OSM, aby mapa odpovidala realite. A
> > protoze jsem prece jenom stale zacatecnik (uz nekolik let), tak
> > bych si
> > rad vyslech vyhrady ke zmene, co jsem zapomnel, co slo udelat lepe
> > a to
> > radeji takto s primym odkazem na chcangeset (nize), nez aby to nekdo
> > pozdeji omylem nasel a divil se proc neco nefunguje.
> > 
> > Zaklad kruhu uz byl na miste jako "construction" a tak jsem jej
> > vyuzil.
> > Stejne tak jsem preroutoval relaci, ktera vedla puvodni rovnou silnici
> > (stejne mam pocit, ze je rozbita na jinych mistech) a zmenil puvodni
> > juncion=circular na roundabout, protoze tam mame konecne tyto znacky.
> > 
> > Mapoval jsem pouze pomoci nocnich fotek (nezaostrene) a jejich GPS
> > pozice z Mapillary. Ani na fotomapach, ani v katastru to jeste neni.
> > 
> > Budu rad za kazde rady a tipy.
> > 
> > http://overpass-api.de/achavi/?changeset=54897143
> > 
> > http://www.openstreetmap.org/changeset/54897143#map=17/49.21855/16.602
> > 05
> >  > 205>
> > 
> > Diky,
> > 
> > Jakub
> > 
> > ___
> > Talk-cz mailing list
> > Talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz




signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-fr] maxspeed:type vs source:maxspeed

2018-01-05 Per discussione marc marc

Le 05. 01. 18 à 20:43, Rodrigo Vivar a écrit :
> Le 30/12/2017 à 13:17, marc marc - marc_marc_...@hotmail.com a écrit :
>  > Le 30. 12. 17 à 13:01, Rodrigo Vivar a écrit :
>  > source:maxspeed est une aberration historique (cela entre en conflit
>  > avec source:maxspeed=survey ou opendata ou mapillary ou jenesaisquoi)
> Ne comprends pas pourquoi "source:maxspeed=sign" en conflit avec 
> "source:maxspeed=survey" si je écris "maxspeed=70" + "source:maxspeed=sign"?

parce qu'il y a 2 usages possibles :
1) source:untag=valeur qui dit d’où vient cette info
par exemple source:heritage=mhs dit que les tag heritage viennent des 
monuments historique
ou source:name=survey dit que quelqu'un a vu ce nom sur place.
2) source:maxspeed décrit le type de panneau. soit un panneau de zone 
valable aussi longtemps qu'il n'est pas annulé. soit un panneau qui ne 
concerne que cette route que jusqu'au prochain carrefour.
cette utilisation historique de source:maxspeed mériterait selon moi 
d'être migrée vers maxspeed:type

>  > a-t-on besoin de dire que tous les panneaux en france sont ceux du code
>  > la route français ?
> Comprends pas question ? Les deux tags ais cité tags sont sur highway, 
> pas sur panneau.

certains pensent que maxspeed:type doit contenir le préfixe du pays 
comme par exemple maxspeed:type=FR:urban
Ou pour le dire autrement, cela dit que toutes les limitations de 
vitesse d’agglomération en France ont comme origine un panneau 
d’agglomération français.
je pense que cette surcharge est inutile, un routeur sait très bien dans 
quel pays est situé le panneau et peux appliquer la bonne valeur selon 
le pays concerné.
On peux donc simplifier avec maxspeed:type=urban
Par comparaison, on ne précise pas que chacune des autoroutes françaises 
est française avec un highway=FR:motorway
On met motorway et on laisse le soin au routeur de savoir qu'elle est en 
France.

Voila pourquoi je pense que les valeurs sign et zone sont suffisante 
pour décrire parfaitement les différents cas.

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

Re: [Talk-us] Parks, again

2018-01-05 Per discussione OSM Volunteer stevea

On January 4, 2018 at 6:21:03 PM PST, Bradley White  
wrote:
>> As you say "feel like Type 2" I think is where it fuzzies in my mind.  Parks 
>> go to 3, 4, even 11 and beyond.  Parks have a wide range of "experiences" 
>> besides 1 and 2.
> 
> So do roads. There are countless kinds of roads, with varying levels
> of importance and physical features. Instead of using a catch-all
> "highway=road" tag, and instead of tagging infinitesimal levels of
> network importance (or any of the other countless possible metrics),
> we develop a classification system that allocates all roads into a
> small set of (semi)-easy-to-work-with-and-understand classes. Some
> roads don't fit well into this system, true. It isn't always clean; it
> can be ambiguous; it continues to be debated over, and that's fine.
> But, for the most part, it has worked, certainly better than the
> all-or-nothing alternatives would have.

I believe you are saying (agreeing) that "roads have many flavors."  Yes.  We 
have many highway=* tags to accommodate those, and while there remain some 
sticky difficulty in a few corner cases, as we map with values motorway, 
primary, trunk, secondary, tertiary... OSM (recall, "Street" is our middle 
name) does well as a result.  The tag "highway=road" is not a "catch-all" tag 
applied recklessly to any and all roads:  for the most part roads are tagged 
with the above (more correct, more precise) values and "highway=road" is left 
for more ambiguous cases, for example when fuzzy aerial imagery suggests a 
road/highway, but little or nothing else is known.  If I got any of that wrong, 
please gently correct me.  Although, I think we are largely in agreement:  we 
both (and many of us in OSM) use the highway= tag with little argument or 
consequence.  (Again, in a few minor cases, discussion continues).

> I agree with previous posters that this is same case with parks. In
> the same way that the fact that there is something different enough
> about a freeway and a narrow county back-road to represent them
> differently in the database, there is something different enough about
> a park I would take a kid to play on the playground for an hour, and a
> park that I can spend half the day mountain biking around in without
> encountering more than a small handful of people, that I think they
> should be differentiated between in our data. I don't think the title
> given to a piece of land should necessarily have bearing on the data
> representation, in the same way "Hampstead Heath" doesn't get
> "natural=heath" just because it's in the name.

I don't know to which previous posters you refer (this is a new thread I've 
broken off) and I am not sure of the point with which you are agreeing.  If I 
had to guess (I prefer not guessing) it seems you mean that OSM could benefit 
from a wide array of park tagging similar to how it enjoys a wide array of 
highway tagging.  I do not disagree, meaning I agree.  Sure, early on we seem 
to have "broken out" (from "generic parks") the specific semantic of 
"national_park."  As I said before, doing so (and where we are now), brings us 
up from one type of park (all of them) up to two (a certain kind of them 
excluding the rest), with two being a very small number.  There might be dozens 
or even hundreds of types of parks, and refining this to exactitude and full 
consensus all across Earth could take OSM decades, with much tedious and messy 
"sausage making" along the way.  Not that it wouldn't be valuable to do so (it 
would be) since as a result of those efforts, OSM might become one of the best 
park maps ever made of our whole planet.  Alas, as "street" IS our middle name, 
we've come closer to the goal of well-describing our highway networks, rather 
than our parks.  Though, parks (and many, many other objects in OSM) are 
somewhat well-represented, I think many agree.  We crawl before we walk, we 
walk before we run.

However, we haven't really well or fully described parks.  We only partially 
describe them, which "isn't nothing."  (I'm happy to accept this, use it to 
enter parks, AND improve on our park entry schema).  As I mentioned,  in 2009 
Apo42 in California got into the (good, in my opinion) habit of adding to a 
(partial, though substantial) statewide parks import a new (back then) tag of 
"park:type" which often blended jurisdiction, type of natural area and/or 
purpose.  For example, some of its values are county_park, state_beach and 
state_historical_reserve.  This was an early, first foray into better 
characterizing what California's Department of State Parks throws into a large 
bin called "parks," (all of them, from beaches to historical reserves) while 
using the state's own data to better sub-categorize them.  As you say, there 
are all kinds of purposes for what humanity calls "park" and it would be good 
for OSM to capture these aspects.  What we haven't done is talk about what vast 
issues this gives rise to, primary:

[Talk-de] Kartendruck hochauflösend

2018-01-05 Per discussione Markus

_Eilt_

Liebe OSMer,

wer kann hochauflösende Karten drucken?
Wen köönnte ich direkt fragen?

Ein Luxus-Yachtkonstrukteur hätte gern für einen Messeauftritt zwei
Kartenausschnitte von OpenSeaMap für Print.
(s. Screenshot)

Darf auch angemessen kosten :-)
Sollte möglichst am WE (Samstag) fertig sein...

z=16
100x50 cm
150 DPI
- Basiskarte
- Seezeichen
- Koordinatengitter
- Häfen

Mit herzlichem Gruss,
Markus

PS: die zugehörigen Kartenausschnitte gibt es per PM
(die Liste lässt keine Anhänge zu)



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

Re: [OSM-talk-fr] maxspeed:type vs source:maxspeed

2018-01-05 Per discussione Rodrigo Vivar


Le 30/12/2017 à 13:17, marc marc - marc_marc_...@hotmail.com a écrit :
> Bonjour,
>
> Le 30. 12. 17 à 13:01, Rodrigo Vivar a écrit :
>> - 5 395 "maxspeed:type"
>> - 63 480 "source:maxspeed"
>> wiki dit "maxspeed:type" en GB et "source:maxspeed" reste du monde
>> Regardant des "maxspeed:type" trouvés en France, vois "created_by
>> StreetComplete 2.3"
>> ca est un effet du brexit ?
> source:maxspeed est une aberration historique (cela entre en conflit
> avec source:maxspeed=survey ou opendata ou mapillary ou jenesaisquoi)

 

Ne comprends pas pourquoi "source:maxspeed=sign" en conflit avec "source:maxspeed=survey" si je écris "maxspeed=70" + "source:maxspeed=sign"?

 

 


> Si StreetComplete permet d'en sortir tant mieux.
> Je trouve malheureusement que maxspeed:type n'est pas mieux ficelé.

 

StreetComplete permet d'en sortir mais pas mieux ?

 


> a-t-on besoin de dire que tous les panneaux en france sont ceux du code
> la route français ?

 

Comprends pas question ? Les deux tags ais cité tags sont sur highway, pas sur panneau.

 


> A mon avis il suffit d'avoir :
> - sign : un panneau limite la vitesse à cet endroit précis (= on peux
> s'en servir + tard pour faire un match avec la photo du panneau).
> le panneau a donc un effet qui s'arrête au prochain carrefour.
> - zone : un panneau limite la vitesse pour toute la zone.
> l'effet s'arrête uniquement au prochain panneau qui l'annule.
> Sauf erreur, urban et zone50 désigne la même chose.
> toutes les zones ne sont qu'un type, la vitesse elle va dans maxspeed.
>
> cela mériterait d'essayer d'harmoniser cela... naïvement.
> naïvement je crois aussi tout aussi inutile de devoir marquer toutes les
> rues d'une zone. ce serrait tellement + maintenable d'avoir une aire qui
> regroupe les points où sont les panneaux début de zone.
>
> Cordialement,
> Marc

 

 


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

[Talk-it] "cabina" metano

ciao, chiedo un parere prima di tutto tecnico.

cos'è esattamente questa "cabina" recintata?

 

 

 

e come la potrei taggare correttamente?
grazie

--enrico





--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-it] disused:

dieterdreist wrote
> io al solito uso "disused:*" ma dipende dal feature, certe cose anche in
> disuso rimangono quel che sono (non le amenity, ma per esempio le
> man_made). Per una trincea non sò se metterei un "disused", per una
> ferrovia si.

premesso che trovo un pochino paradossale che nonostante il mantra "non si
mappa per il rendering" stiamo proprio discutendo sul fatto che un oggetto
si veda lo stesso oppure no anche se in disuso, insisto ancora con il caso
di un'abitazione civile non più utilizzata, se uso il prefisso disused:
sparirà e non è corretto perchè il building in quanto tale c'è ancora, non
siete d'accordo? come dovrei fare in questo caso?

--enrico





--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

2018-01-05 Per discussione Christian Quest

Pour moi c'est à éviter car ça fait dépendre ton rendu d'un service tiers
dont on ne contrôle pas la disponibilité.

Si les tuiles externes d'ombrage ou de courbe de niveau ne sont pas
dispo... on fait quoi ?

Un serveur de tuile doit fonctionner en autonomie. Sur un client, c'est
différent, tu peux mixer les tuiles si tu veux, vu que de toute façon tu
dépends en général de tuiles tierces.

Je digresse un peu... le recours bien facile aux services et données tiers
c'est "pratique", mais casse gueule aussi.
Les très nombreux utilisateurs des fonds mapquest en ont fait les frais...
ceux qui utilisent les services de mapzen vont le découvrir à la fin de
mois (mapzen plie boutique).

Comme les médocs, les API c'est bien, en abuser ça craint ;)


Le 5 janvier 2018 à 18:59, Vincent Frison  a
écrit :

> Merci Christian pour ces précisions.
>
> Donc l'idée c'est est d'avoir un MNT en local et une moulinette permettant
> de le convertir à la volée en jolis tuiles rasters avec transparence, puis
> bien configurer mapnik pour qu'il les utilise.
>
> Mais là ça serait donc une solution propre, et du coup un peu complexe...
>
> Par curiosité, n'y aurait il pas une solution beaucoup plus simple (mais
> surement moins propre) consistant à réutiliser un serveur de tuiles
> (d'ombrage ou de courbes de niveaux) et l'ajouter en transparence sur les
> tuiles existantes ?
>
> J'ai l'impression que c'est vraiment ce que fait http://opensnowmap.org
> lorsqu'on utilise la rendu OSM standard comme background car si on se
> déplace rapidement on voit d'abord les tuiles OSM standard puis le
> relief qui se rajoute après (il y a un petit décalage de quelques
> millisecondes). Par contre si on laisse le background par défaut SnowMap,
> là il n'y a aucun décalage ce qui laisse supposer que c'est la solution
> propre: il a intégré le relief directement dans son rendu et il n'y a donc
> qu'un seul layer... ça se tient à peu près ce que je dis ? :)
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [Talk-cz] Statistika využití CZ:IPRPraha:ortofoto

2018-01-05 Per discussione r00t

> Hm... předpokládám, že IPR do source changesetu neuvádíš, co?
Zdroje jsem si do JOSM pridaval hned jak se pouziti IPR povolilo a takhle se
zdroje tehdy v oficialnim seznamu jmenovaly. To ze se pozdeji prejmenovaly na
"Praha IPR latest ortophoto" atd. uz jsem nemel duvod resit - do nastaveni
zdroju WMS opravdu kazdy den nelezu abych kontroloval jestli se vsechno
jmenuje spravne...
Ten nazev urcite neni nejaky muj osobni vysmysl a uz vubec neslo o to nejak
cilene "IPR" jako source neuvadet.



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

Re: [Talk-cl] Donación de servidor Dell PowerEdge R310

2018-01-05 Per discussione Julio Costa Zambelli

Hola Juan,

Por supuesto que lo recibiremos felices. Si quieres enviame un mensaje para
coordinar el traslado.

Saludos,

Julio Costa Zambelli
Fundación OpenStreetMap Chile

julio.co...@openstreetmap.cl

https://www.openstreetmap.cl/
Cel: +56(9)89981083

On 5 January 2018 at 12:04, Juan Pizarro  wrote:

> Hola,
>
> hace algunos meses, quizás años, le comente a Julio que tengo un servidor
> que quiero donar, tiene poco uso, una año en ambiente de desarrollo.
>
> Me interesa saber si están interesados?
>
> Las características son:
>
>- 1 224-8312 PER310 Chassis, Up to 4 HP HD w/LCD
>- 1 313-7839 Bezel
>- 1 313-7919 BASEBOARD MANAGEMENT CONTROLLER
>- 1 313-9091 DVD+/-RW, SATA
>- 1 317-2022 Memory for 1CPU Platform
>- 1 317-2025 4GB,2x2GB,1333MHz,2R RDIMM
>- 1 317-2306 X3450,2.66G,4C,8M
>- 1 330-4140 Slide Ready Rail with Cbl Mng Arm
>- 1 330-5113 PWR CRD,120V,10FT,wallplug
>- 1 330-5113 PWR CRD,120V,10FT,wallplug
>- 1 330-5280 DELL MANAGEMENT CONSOLE
>- 1 330-8175 R1,Add-in S6i/H2/H7,2HPHD
>- 1 330-8183 CBL,SAS,6IR,ADPT,HP,HDD
>- 1 330-8207 PowerEdge R310 Heatsink
>- 1 330-8208 Shipping for PowerEdge R310
>- 1 330-8209 PwrSply,Rdnt,400W
>- 1 330-8866 ODD Cable, PowerEdge R310
>- 1 330-8869 Edocs and OpenManage DVD
>- 1 341-8728 500GB,7.2K SATA 3.5 HP
>- 1 341-8728 500GB,7.2K SATA 3.5 HP
>- 1 342-0767 SAS 6iR SAS internal RAID adapter
>- 1 420-6320 NO OPERATING SYSTEM
>- 1 430-2008 ONBD DUAL NTWRK ADPTR
>- 1 909-7897 HW WRTY + SVC,PER310,UNY,INIT,LA
>- 1 928-4570 BASIC NBD OS,PER310,UNY,INIT,LA
>- 1 909-7858 HW WRTY,PER310,UNY,EXT,LA
>- 1 925-7432 BASIC NBD OS,PER310,UNY,2YR EXT,LA
>- 1 909-7917 NBD,PER310,DECLINED PRO SPT,LA
>- 1 911-0418 ONSITE INSTL DECLINED LA/BZ
>- 1 917-7479 INFO, BASIC SPT 1YR SATA HDD, LA
>
>
> Saludos
>
> --
>
> *Juan Pizarro*
> *E-Mail:*
> *Twitter: *
> *LinkedIn: *
> jpizar...@gmail.com
> @jpizarrom 
> jpizarrom 
>
> -
> OpenStreetMap.cl: El Mapa Libre del Mundo
>
> ___
> Talk-cl mailing list
> Talk-cl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cl
>
>
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

Re: [Talk-cz] Jednosměrka

2018-01-05 Per discussione Jiří Komárek

Nejsem si 100 % jistý, ale řekl bych, že "chyba" bude v navigaci: zřejmě 
neumí navigovat podle ročních období. Dotaz bych vedl na vývojáře 
navigace (a tady si nejsem jist, zda-li budou ochotní takovouto 
funkcionalitu přidat. Přeci jen, je to dost speciální případ)



On 5.1.2018 19:51, marek wrote:


Upravil jsem ulici na jednosměrku, aby v zimních měsících byla 
průjezdná jen jedním směrem, ale navigace mě stále vede oběma směry. 
Tak nevím kde je chyba.


https://www.openstreetmap.org/edit#map=19/50.73378/15.18578

Marek Polák



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


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

[Talk-cz] Jednosměrka

2018-01-05 Per discussione marek


Upravil jsem ulici na jednosměrku, aby v zimních měsících byla průjezdná jen 
jedním směrem, ale navigace mě stále vede oběma směry. Tak nevím kde je chyba.
https://www.openstreetmap.org/edit#map=19/50.73378/15.18578
 
Marek Polák
 

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

Re: [Talk-cz] Statistika využití CZ:IPRPraha:ortofoto

"IPR Praha souhlasí s využíváním ortofotografií, které poskytuje
prostřednictvím Geoportálu hl. m. Prahy, za účelem aktualizace a doplňování
databáze OpenStreetMap, přičemž vzniklá vektorová data smí být vložena do
OSM pod licencí ODbL za předpokladu, že IPR bude uveden v seznamu
přispěvatelů do OSM a takto vzniklá data budou mít IPR uveden jako svůj
zdroj."

1) Ještě nějaké alternativní formy plnění tohoto požadavku? Koukám na
source u objektů (to se zatím zdá být spíše zanedbatelné), source u
changesetů, budu řešit imagery_used u changesetů...
2) Jak mám z "giswa1.mag.mepnet.cz" poznat, že jde o IPR? Jsou všechny
letecké snímky odtud IPR?

Ono asi nevadí, pokud mi v těch statistikách bude něco chybět, jen pak bude
těžší obhájit to, že jsme je uváděli jako zdroj...

2018-01-05 18:47 GMT+01:00 Matej Lieskovský :

> Hm... předpokládám, že IPR do source changesetu neuvádíš, co?
>
> 2018-01-05 18:36 GMT+01:00 r00t :
>
>> Ahoj,
>>
>> > Tahám to přímo z changesets-latest.osm, takže mám naopak jen tady a
>> metadata changesetů.
>> > Vzhledem k tomu, že jsem předpokládal alespoň substring "IPRPraha", tak
>> mi asi iD unikl. Zkusím to nějak opravit.
>> Pouzivam IPR v JOSM a vrstvy se mi pojmenovaly:
>>  giswa1.mag.mepnet.cz: Letecké snímky
>>  giswa1.mag.mepnet.cz: Letecké snímky - mimovegetační
>>  giswa1.mag.mepnet.cz: Letecké snímky - okolí Prahy
>> ..."ipr" tam neni ani jednou... takze tech changesetu bude mozna jeste o
>> neco vic.
>>
>>
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-it] disused:

2018-01-05 Per discussione Giorgio Limonta




> Veramente è stato oggetto di tante discussioni, e una volta tanto si era
> giunti a una conclusione...

> Considera un ristorante taggato con amenity=restaurant.
> Un giorno questo ristorante chiude, come riflettere il cambiamento sulla
> mappa?
> Se aggiungi disused=yes, il ristorante continuerà a comparire con la sua
> icona, verrà ancora restituito a chi interroga i dati cercando un
> ristorante, ecc.
> L'utilizzo di una chiave diversa ti permette invece di aggiornare
>l'informazione evitando confusioni.

Perfettamente d'accordo e trovo inoltre personalmente molto utile il prefisso 
"disused:" avendo intrapreso con il Politecnico di Milano alcuni studi sulla 
mappatura e il monitoraggio delle attività commerciali utilizzando OSM (vedi il 
link seguente http://www.urbecom.polimi.it/mappatura_monitoraggio_osm/) 
Buona serata a tutti
GiorgioL


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

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

2018-01-05 Per discussione Vincent Frison

Merci Christian pour ces précisions.

Donc l'idée c'est est d'avoir un MNT en local et une moulinette permettant
de le convertir à la volée en jolis tuiles rasters avec transparence, puis
bien configurer mapnik pour qu'il les utilise.

Mais là ça serait donc une solution propre, et du coup un peu complexe...

Par curiosité, n'y aurait il pas une solution beaucoup plus simple (mais
surement moins propre) consistant à réutiliser un serveur de tuiles
(d'ombrage ou de courbes de niveaux) et l'ajouter en transparence sur les
tuiles existantes ?

J'ai l'impression que c'est vraiment ce que fait http://opensnowmap.org
lorsqu'on utilise la rendu OSM standard comme background car si on se
déplace rapidement on voit d'abord les tuiles OSM standard puis le
relief qui se rajoute après (il y a un petit décalage de quelques
millisecondes). Par contre si on laisse le background par défaut SnowMap,
là il n'y a aucun décalage ce qui laisse supposer que c'est la solution
propre: il a intégré le relief directement dans son rendu et il n'y a donc
qu'un seul layer... ça se tient à peu près ce que je dis ? :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cz] Statistika využití CZ:IPRPraha:ortofoto

Hm... předpokládám, že IPR do source changesetu neuvádíš, co?

2018-01-05 18:36 GMT+01:00 r00t :

> Ahoj,
>
> > Tahám to přímo z changesets-latest.osm, takže mám naopak jen tady a
> metadata changesetů.
> > Vzhledem k tomu, že jsem předpokládal alespoň substring "IPRPraha", tak
> mi asi iD unikl. Zkusím to nějak opravit.
> Pouzivam IPR v JOSM a vrstvy se mi pojmenovaly:
>  giswa1.mag.mepnet.cz: Letecké snímky
>  giswa1.mag.mepnet.cz: Letecké snímky - mimovegetační
>  giswa1.mag.mepnet.cz: Letecké snímky - okolí Prahy
> ..."ipr" tam neni ani jednou... takze tech changesetu bude mozna jeste o
> neco vic.
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-it] standardizzazione stradario comunale

2018-01-05 Per discussione totera

Andrea Musuruane wrote
> Ho modificato le seguenti pagine della wiki:
> https://wiki.openstreetmap.org/wiki/IT:Key:name
> https://wiki.openstreetmap.org/wiki/IT:Italian_Roads_Tagging#name
> https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade
> 
> Le prime due ora fanno riferimento all'ultima, in modo da avere un unico
> posto dove sono inserite le regole per i nome delle strade.
> 
> Ho cercato di inserire - in modo sintetico - le informazioni principali
> riportate dall'ISTAT, evidenziando le eccezioni di OpenStreetMap (nomi NON
> tutti in maiuscolo, uso di lettere accentante, prima lettera maiuscola,
> ecc).

Rispetto alle convenzioni che usavamo la variazione più significativa
riguarda i nomi composti da giorno e mese.
Siamo d'accordo ad accogliere questo punto delle direttive Istat, passando
per il giorno dalle cifre al numero scritto per esteso?
Se sì, è il caso di implementare una modifica automatica o procediamo
manualmente?




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-cz] Statistika využití CZ:IPRPraha:ortofoto

2018-01-05 Per discussione r00t

Ahoj,

> Tahám to přímo z changesets-latest.osm, takže mám naopak jen tady a metadata 
> changesetů.
> Vzhledem k tomu, že jsem předpokládal alespoň substring "IPRPraha", tak mi 
> asi iD unikl. Zkusím to nějak opravit.
Pouzivam IPR v JOSM a vrstvy se mi pojmenovaly:
 giswa1.mag.mepnet.cz: Letecké snímky
 giswa1.mag.mepnet.cz: Letecké snímky - mimovegetační
 giswa1.mag.mepnet.cz: Letecké snímky - okolí Prahy
..."ipr" tam neni ani jednou... takze tech changesetu bude mozna jeste o neco 
vic.



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

Re: [Talk-cz] petr1868: data znicena LPIS importem na Zernovce

2018-01-05 Per discussione Pavel Machek

On Fri 2018-01-05 15:55:39, Zdeněk Pražák wrote:
> no pokud to mohu posoudit podle IPR Ortofota tak jsem to opravil

No, dekuju. Smazu zbyvajici nudle, a pridam zpet ploty kde maji byt.

Myslim ze tam byval zmapovany pristresek, ten zda-se nekdo smazal. Dam
ho zpet.

Jen uvazuju co s tema lpis tagama. Smazat? Nechat? Zatim sem je
nechal. 
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-it] disused:

2018-01-05 Per discussione Martin Koppenhoefer

2018-01-05 14:27 GMT+01:00 demon.box :

> ...strano che non interessi quasi a nessuno questo argomento
>
> chiedo scusa ma voi utilizzate disused=yes o il prefisso disused:  ??




io al solito uso "disused:*" ma dipende dal feature, certe cose anche in
disuso rimangono quel che sono (non le amenity, ma per esempio le
man_made). Per una trincea non sò se metterei un "disused", per una
ferrovia si.

In generale, per dire una cosa non più in uso, esistono questi prefissi (in
ordine dal buono al niente):
disused - non più usato, però potrebbe esserlo con poco sforzo
abandoned - abandonato e solo riutilizzabile con più sforzo (esempio alberi
tra i binari), molto più frequente del prefisso disused!
demolished - rimosso, ma tracce significative sono ancora visibili
razed - completemente rimosso, forma del terreno cambiata o simile.


in più c'è il prefisso "ruins:" (non troppo utilizzato:
https://taginfo.openstreetmap.org/search?q=ruins%3A ), e probabilmente
altri.

Ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Utente che cancella landuse e crea fiumi

2018-01-05 Per discussione Alessandro Rubini

> La segnalazione al DWG credo sia necessaria: quando l'utente non risponde
> agli avvisi di smetterla, e` essenziale imporgli la lettura di un messaggio
> che gli chiarisca che il suo comportamento sta danneggiando OSM.

Secondo me semplicemente non si accorge che ci siano messaggi per lui
quando si autentica per editare (se non te lo aspetti non lo noti,
secondo me).  E allora il blocco dovrebbe aiutare a far capire che
c'e` un problema.

Pero`, forse, con tutto il tempo che ci si sta investendo conviene
fargli una telefonata e chiarire velocemente. C'e` un suo CV in rete
con i numeri personali. Stesso nome, stesso campo, stessa
regione. Immagino sia lui.


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

Re: [Talk-cz] Výzva k hlasování - bazény Fell3 - smazat nebo private

2018-01-05 Per discussione Jan Macura

Zdravím,

podle Majky je to 5000 polygonů. Řekl bych, že cca 10 lidí se tady v
diskusi vyjádřilo. Tak si každý vezmeme 500 bazénů, srovnáme je s licenčně
kompatibilními podklady a nalezeno => ponechat, nenalezeno =>vyhodit.

Příjemný víkend ;-)
 H.

2018-01-05 17:27 GMT+01:00 Jan Chren (rindeal) :

> 2018-01-05 2:05 GMT+01:00 Miroslav Suchý :
>
>> Budu delat dablova advokata:
>>
>> Dne 4.1.2018 v 23:24 Jan Chren (rindeal) napsal(a):
>> > 1) Spousty tech bazenu je ve skutecnosti nafukovacich nebo se vubec
>> > nejedna o bazeny, ale o koi jezirka. -> *Spatna data*
>>
>> Nafukovaci bazen je bazen. Otazka je jak mapovat, ze tam pres zimu neni.
>>
>
> To je pokus o trolling nebo byste snad chtel mapovat i zaparkovana auta?
>
>
>>
>> > 2) Vyber zmapovanych lokalit je evidentne +/- nahodny, a to i v ramci
>> > jednotlivych obci. -> *Nekompletni data*
>>
>> A my mame nekde kompletni data? Ja ve svem okoli mapuji take +- nahodne.
>>
>
> V pripade, ze je nekdo ochoten pridavat 5000+ zcela novych objektu, bych
> predpokladal systematicnost ala mapathony, kdy se oblast rozdeli na 2D
> matici. Nebo alespon kompletnost v ramci vesnice s 500 obyvateli, ale ani
> to neni tento pripad. Tento uzivatel pracoval tak, ze do nejake vesnice
> pridal 5 bazenu, pak se presunul o 100km dal, tam zmapoval 50 bazenu, atd.
> napric celym statem.
>
>
>>
>> > 3) Na vestavene bazeny do 40m2 neni potreba zadne stavebni povoleni,
>> > takze o nich nikde nejsou ani zadne zaznamy pro pripadnou kontrolu.
>> > Survey bude nekdo asi taky tezko provadet. Pro cteni ze satelitnich
>> > snimku je vetsina tech bazenu prilis mala. -> *Tezce ci zcela
>> > neoveritelna data*
>>
>> V mistech kde jsou dobre satelitni mapy to overitelne je.
>>
>
> Male soukrome bazenky na necich zahradach jdou spravne zakreslit jen z
> ortofotomap. Oblast mapovani daneho uzivatele se vsak malokdy protina s
> oblastmi s legalne dostupnymi ortofotomapami.
>
>
>>
>> > 4) A konecne, samotny smysl mapovani je pochybny, protoze se jedna
>> > vetsinou o nevyznamne mini stavby u nekoho na zahrade. -> *Zbytecna
>> data*
>>
>> Co jsou to zbytecna data? Zkusenost me naucila, ze co prijde zbytecne me
>> (napr. detaily o zeleznicich) je cenna informace pro jineho.
>> Dokazu si predstavit z takovychto dat interpolovat data o spotrebe vody
>> pro bazeny v danem regionu.
>>
>
> Nelze srovnavat male soukrome bazeny s verejnou zeleznicni siti. A pro
> jistotu pripominam, ze proti mapovani spravne otagovanych vestavenych
> bazenu dobre viditelnych ze vzduchu/zeme, se tu nikdo nestavi.
> 
>
>>
>> Mirek
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>
>
> Shrnul bych to jeste tak, ze se tady jedna o uzivatele, ktery se rozhodl
> mapovat ve velkem, mapovat spatne a mapovat z nejasnych zdroju. Proto je
> jakykoliv hromadny "fix" ala `access=private` zbytecnym pokusem o
> zaplatovani ohromneho osunteleho pytle. Ta data, ktera pridal do databaze
> zaroven nejsou nijak vyjimecna, vzacna ci kriticka, a proto neni potreba
> usilovat o jejich zachovani na ukor tech chudaku, kteri by to po nem
> opravovali. Kazdy muze ty bazeny, ktere stoji za zmapovani, zmapovat znovu
> a spravne.
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] petr1868: data znicena LPIS importem na Zernovce

2018-01-05 Per discussione Pavel Machek

Ahoj!

> "Ahoj!
> 
> Preplacnout LPISem existujici data neni vzdy dobry napad. Viz nesmysl
> ktery vznikl na
> 
> http://www.openstreetmap.org/#map=19/50.00352/14.74784
> 
> Autora muzu ujistit ze takhle to tam opravdu nevypada, kdyby to
> nahodou nebylo jasne; puvodni data odpovidala.
> "
> 
> 
> 
> Tady bych to viděl na nějaký bordel v LPIS:
> 
> https://openstreetmap.cz/#map=18/50.00380/14.74698=oONL
> 
> 
> 
> 
> Pravděpodobně se snaží získat dotace na co největší zatravněnou plochu.
> Takže místa, kde je jen hlína zahrnuta nejsou. Ale proč je z toho v LPISu
> orná půda fakt netuším.
> 
> 
> "
> 
> 
> 
> Hmm,
> 
> 
> landuse=farmland, crop=grass

No problem hlavne je nekdo (petr1868) prevzal cast puvodniho znaceni
-- barrier=fence. A muzu svet ujistit, ze plot nenasleduje hranici
hlina -- trava :-).

To znaceni landuse=farmland, crop=grass taky neodpovida, je to louka
na ktery jsou kone, ne pole na kterym se pestuje trava...
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Statistika využití CZ:IPRPraha:ortofoto

Tahám to přímo z changesets-latest.osm, takže mám naopak jen tady a
metadata changesetů.
Vzhledem k tomu, že jsem předpokládal alespoň substring "IPRPraha", tak mi
asi iD unikl. Zkusím to nějak opravit.
Díky za info!

2018-01-05 17:33 GMT+01:00 Pavel Zbytovský :

> Ahoj,
>
> co se týče té statistiky, nejsem si jistý jestli máš započítané i editace
> z editoru iD. Přidával jsem obě vrstvy pomocí své TMS-proxy - viz
> [1][2][3]. Ovšem nevím kdy se to dostalo do main website (a vlastně do
> JOSMu taky - layer-index je společný).
>
> Každý kdo v iD změnil libovolnou věc při zapnuté této vrstvě, bude mít v
> klíči imagery_used u changesetu buď "IPR ortofoto Low-Vegetation
> (tmsproxy)" nebo "IPR ortofoto LAST (tmsproxy)" .. případně oddělené
> středníkem.
>
> Myslím ale, že údaje o changesetech v planet.osm nejsou, tudíž by to bylo
> potřeba extrahovat je nějak jinak (možná planet i s historií?)
>
> P.
>
> [1] https://github.com/osmlab/editor-layer-index/pull/300
> [2] http://osm-a.zby.cz/tiles_ipr_vege.php
> [3] http://osm-a.zby.cz/tiles_ipr_last.php .. nějaké rozbité teď
>
>
> On Fri, Jan 5, 2018 at 4:54 PM Vratislav Filler  wrote:
>
>> Ahoj,
>>
>>
>>
>> hojně jsem využíval pro ověření existence či rozsahu cyklopruhů (korekce
>> potom, co to tam nejdřív namalujeme od oka), a pro cyklo infra vůbec,
>> mimovegetační pro ověření přítomnosti a charakteru cest a chodníků, apod.,
>> pro bezmotorovou byly starší ortofoto málo použitelné. Výhodou je i častá
>> aktualizace, právě u cykla, kde se stav docela často mění.
>>
>> Kdyby se někd hecnul, tak podle toho může v Praze udělat předsunuté
>> stopčáry.
>>
>>
>>
>> V.
>>
>>
>>
>> __
>> > Od: Jethro 
>> > Komu: OpenStreetMap Czech Republic 
>> > Datum: 03.01.2018 16:38
>> > Předmět: Re: [Talk-cz] Statistika využití CZ:IPRPraha:ortofoto
>> >
>> Zdar,
>> určitě pruhy, prezentovat jako "Zlepšení pro mnohé automobilové
>> navigace" ;-) Já jsem jich taky zmapoval docela dost právě podle (a
>> díky tomu, že se uvolnily) IPR ortofoto.
>> MSF
>> Jethro
>>
>> 2018-01-03 15:47 GMT+01:00 Jan Martinec :
>> > Ahoj,
>> >
>> > to je super, že to aspoň pár lidí využilo.
>> > Díky za uznání, ale nějak mě nenapadá jedna velká konkrétní věc, kterou
>> jsem
>> > s tím dělal - většinou to bylo menší využití v rámci úprav něčeho
>> většího -
>> > budovy, průchody, vodní toky.
>> >
>> > Možná pražské mosty - přidával jsem pomocí ortofota pilíře, a zcela
>> určitě
>> > jsem udělal i spoustu dopravních pruhů (počet, směr, omezení, řazení v
>> > nich).
>> >
>> > Každopádně díky, žes to zařídil - takhle kvalitní podklady kdybychom tak
>> > měli všude...
>> >
>> > Zdar,
>> > Honza Piškvor Martinec
>> >
>> >
>> > Dne 3.1.2018 v 14:30 Matej Lieskovský napsal(a):
>> >>
>> >> Ahoj!
>> >>
>> >> Jak si možná vzpomínáte, před necelým rokem jsem pomohl získat povolení
>> >> k využití ortofotek IPR. Díky tomu nyní máme přístup k snímkům celé
>> >> Prahy a okolí, které jsou 2x ročně aktualizovány. V rámci dohody jsem
>> >> slíbil počítání statistik. Zatím čekám na zveřejnění nového planet.osm,
>> >> ale tady jsou statistiky k 25.12.:
>> >>
>> >> Data IPR využilo 8 uživatelů ve 396 change setech, které se týkaly
>> 46890
>> >> objektů.
>> >>
>> >> Až budu mít zpracovaná novější data, tak bych jim tohle poslal jako
>> >> součást většího reportu.
>> >>
>> >> Pokud proti tomu nikdo nic nemá, tak bych tam také použil frázi cca
>> typu
>> >> "Dovolte, abych Vám jménem české komunity přispěvatelů do OSM
>> poděkoval."
>> >>
>> >> Taky bych tam rád napsal nějaká "pěkná" využití těch fotek. Překreslení
>> >> tramvajových tratí bylo z velké části pomocí IPR fotek, já jsem dělal
>> >> pár zlepšení porkytí parků (Valdštejná zahrada, Vojanovy sady,
>> Malešický
>> >> park, Centrální park, Vyšehrad...), ale vykoukat další věci z těch
>> >> changesetů je trochu nad moje možnosti. Víte někdo o něčem, co by se
>> >> dalo takhle vypíchnout? Vím, že Piškvor toho taky udělal hodně, ale
>> >> zatím nevím, jak to pěkně popsat.
>> >>
>> >> Ať se daří!
>> >>
>> >> Matej
>> >>
>> >> PS: Jo, snažím se dát IPR něco, co zní dobře. Oni to použijí jako
>> >> "podívejte se, jak je IPR užitečný" a výměnou za to nám snad do
>> budoucna
>> >> dají více dat.
>> >>
>> >>
>> >> ___
>> >> Talk-cz mailing list
>> >> Talk-cz@openstreetmap.org
>> >> https://lists.openstreetmap.org/listinfo/talk-cz
>> >>
>> >
>> >
>> > ___
>> > Talk-cz mailing list
>> > Talk-cz@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-cz
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>>

Re: [Talk-it] disused:

2018-01-05 Per discussione totera

demon.box wrote
> ...strano che non interessi quasi a nessuno questo argomento

Veramente è stato oggetto di tante discussioni, e una volta tanto si era
giunti a una conclusione...

Considera un ristorante taggato con amenity=restaurant.
Un giorno questo ristorante chiude, come riflettere il cambiamento sulla
mappa?
Se aggiungi disused=yes, il ristorante continuerà a comparire con la sua
icona, verrà ancora restituito a chi interroga i dati cercando un
ristorante, ecc.
L'utilizzo di una chiave diversa ti permette invece di aggiornare
l'informazione evitando confusioni.

Ciao e buon anno a tutti!



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-talk-fr] review_requested=yes sans commentaire pour aider les nouveaux

2018-01-05 Per discussione marc marc

Le 05. 01. 18 à 18:09, pepilepi...@ovh.fr a écrit :
>> je relance le message car je pense que ce serrait utile d'aider ceux qui
>> se posent des questions sur leur contribution.
>> je retourne régulièrement voir ce qu'ils ont fait après mon message,
>> ceux qui continue à être actif ont généralement corrigé leurs erreurs.
>> le lien affiche les nouveaux qui n'ont eu aucun commentaire.
>>> https://resultmaps.neis-one.org/osm-suspicious?country=140=96=10=c=review_requested%3Dyes=t=>=10=d=n=t
>> si on arrive à traiter cette liste de demande d'aide, on peux toujours
>> changer le critère pour viser + large.

> Tout ce qu'il faut faire c'est mettre un commentaire expliquant les 
> erreurs ou constatant simplement que c'est tout bon ?

Oui :)
Je rajoute une ligne de bienvenue pour faire sympa.
Mais je laisse le soin au contributeur initial de corriger lui-même ses 
erreurs pour apprendre.Si on corrige sans lui dire, il l'ignore.
Il n'y a que si c'est grave ou compliqué à corriger pour un débutant que 
je corrige moi-même (par exemple un nœud déplacé par mégarde sur une 
grande distance ou un relation effacée impossible à restaurer avec iD).
Mais si tu souhaites faire autrement, n'hésites pas.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Grenzen und Wege

2018-01-05 Per discussione Martin Koppenhoefer

Am 5. Januar 2018 um 17:49 schrieb Markus :

> Die Grenze hingegen ist in Ländern mit Geodäsie immer exakt vermessen,
> mit Messpunkten und Geraden dazwischen.



grade bei Flussgrenzen gibt es das oft nicht, weil ja der Fluss die Grenze
ist. Für jede einzelne Grenze nachzuforschen, wie sie definiert ist, macht
sicherlich unglaublich viel (Recherche-) Arbeit, aber so ganz falsch wäre
das nicht. Von "offizieller" Seite gibt es unterschiedliche Versionen
derselben Grenze, je nach Maßstab und je nachdem wen man fragt (nicht so
selten gibt es unterschiedliche Auffassungen bei Nachbarn über den
Grenzverlauf).

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

Re: [Talk-it] disused:

2018-01-05 Per discussione Ivo Reano

Rispondo solo perché quando dici

Il giorno 5 gennaio 2018 14:27, demon.box  ha scritto:

> ...strano che non interessi quasi a nessuno questo argomento
>

Mi sento tirato in causa personalmente, anche se sono un osmapper junior
(non come età anagrafica [ah, ah, aaah!])
Credo che la discussione sia utile a quelli che come me iniziano a mappare
oltre il proprio interesse ristretto.
Direi che questo prefisso disused, mi toglie diversi pensieri rimasti in
sospeso!
E penso a: alpeggi abbandonati, borgate disabitate (no, forse qui serve un
altro tag, ma per piccolissimi gruppi di case?), mulini, edicole votive,
strade forestali, e mi fermo per non allungare troppo.
Insomma il tag da usare quando identifichi la casa che però non è più usata
e nemmeno usabile se non con un piccolo o grande lavoro
La manna direi!
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] review_requested=yes sans commentaire pour aider les nouveaux

2018-01-05 Per discussione pepilepi...@ovh.fr

Le 04/01/2018 à 18:33, marc marc a
écrit :

Bonjour,

https://resultmaps.neis-one.org/osm-suspicious?country=140=96=10=c=review_requested%3Dyes=t=>=10=""

si on arrive à traiter cette liste de demande d'aide, on peux toujours
changer le critère pour viser + large.

Cordialement,
Marc

Bonsoir,
Tout ce qu'il faut faire c'est mettre un commentaire expliquant
les erreurs ou constatant simplement que c'est tout bon ?

Le 02. 12. 17 à 14:35, Marc M. a écrit :

Bonjour,

Le tag permet à un contributeur qu'il souhaite un 2ieme avis sur sa modif.
Je regarde régulièrement les changeset avec ce tag, le plus souvent
utilisé par un contributeur récent.
C'est un outil pratique pour aider à s'améliorer.
A ma demande, Pascal Neis l'auteur du site web ci-dessous, a ajouté une
option pour n'afficher que les changeset sans commentaire, ceux qui sont
le + susceptible d'avoir besoin d'un coup d’œil.
Pour la France, cela donne

https://resultmaps.neis-one.org/osm-suspicious?country=140=96=-1=review_requested%3Dyes=t=%3E=10="">

Cela serrait utile qu'on le fasse à plusieurs :)
Pour que cette nouvelle option fonctionne, il faut bien sur prendre la
peine de mettre un petit mot sur le changeset (même quand il n'y a rien
à corriger).
Pour ma part, je constate qu'environ la moitié des réactions sont prise
en compte (j’imagine que les autres ne sont peut-être pas vu que osm
envois uniquement l'info par email, susceptible d'aller en spam, sans
notification via le site)

Cordialement,
Marc

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

Joyeux Noël et Bonne Année 2018

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

Re: [Talk-de] Craftmapping

2018-01-05 Per discussione Manfred A. Reiter

Hallo Frederik,

+1

Am 5. Januar 2018 um 12:09 schrieb Moritz :

> +1 für deine Ansichten
>
> Es hat auf jeden Fall gemacht, dass die OSMF jetzt ein craftmappendes
> Mitglied mehr hat.
>

@Moritz - das sind die richtigen Konsequenzen, die viele aus der dt.
Community auch ziehen müssten!
... wie man bedauerlicherweise erst neulich gesehen hat. :(

[...]

-- 
## Manfred Reiter - -
## N 49° 25' 11.028" E 06° 50' 47.328"
## www.weeklyOSM.eu
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Grenzen und Wege

2018-01-05 Per discussione Markus

Hallo Martin,

> Wasserwege (Bach/Fluss) markieren oft grenzen, bzw sind deckungsgleich mit 
> Grenzen. Sollte ich dann eine Grenzen über den Way zeichnen oder den Weg mit 
> den bekannten tags füllen und den jeweiligen Abschnitt dann in die Relation 
> aufnehmen?
> 
> Im Wiki wird empfohlenen zwei getrenne Ways zu erstellen, im Bezug auf die 
> erleichterte Veränderbarkeit. 

Ja, das ist die sinnvollste Variante.

Flüsse werden meist nur rudimentär gemappt:
"ungefähr dem Luftbild (zu irgendeinem vergangenen Zeitpunkt) folgend"
meist mit langen Segmenten Kurven überspringend.

Flussbette sind zwar genauer, bilden aber die "Uferlinie" nur bei einen
bestimmten Wasserstand ab - und der verändert sich - und damit die
Uferlinie dauernd.

Selbst da, wo Kanuten den Fluss mit Kajak und GPS mappen, bilden sie die
Flusslinie als Linie der Hauptströmung ab, also da, wo der Fluss am
Tieften ist - und das ist in mäandrierend Flüssen immer in der Aussenkurve.

Die Grenze hingegen ist in Ländern mit Geodäsie immer exakt vermessen,
mit Messpunkten und Geraden dazwischen.

In weniger entwickelten Ländern gelten oft Fliessgewässer als Grenzen.
Da wissen aber die Nachbarn, wo die Grenze liegt und was sie genau wofür
und für wen bedeutet. Meist sind das aber keine harten Grenzen, sondern
eher "Grenzbereiche". Und bei z.B. kleinen Flussinseln weiss man nicht
so genau, wem die nun "gehören".

On OSM sind vermutlich die wenigsten Grenzen aus amtlichen Quellen,
und die Flüsse sowieso nicht.

Deshalb würde ich sowohl (neue) Flüsse als auch (neue) Grenzen einfach
so genau zeichnen wie es die Datenquelle hergibt.
Und immer als zwei getrennte Linien.

Nur so kann man später die Grenze oder den Fluss verbessern.

Gruss, Markus



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

Re: [Talk-de] Craftmapping

2018-01-05 Per discussione Mark Obrembalski


Am 04.01.2018 um 15:39 schrieb Frederik Ramm:

Hallo,

mich treibt seit einigen Monaten eine Idee um. Mir scheint, dass das
"Craftmapping" bei OSM und vorallem auch im "politischen" Bereich, der
OSMF, zunehmend unter den Tisch fällt.

"Craftmapping" (zu deutsch: "handwerkliches Kartieren"?) ist in meinen
Augen die traditionelle OpenStreetMap-Arbeit: eine Gegend, die man
selber kennt, mit allen verfügbaren Mitteln (vorallem mit Ortsbegehung)
auf die Karte zu bringen.


Das ist sicher etwas, was nicht unter den Tisch fallen sollte, denn 
vieles ist auf andere Weise gar nicht in guter Qualität zu ermitteln. 
Aber nimmt diese Art zu mappen denn tatsächlich ab? Und welche 
unerfüllten Wünsche haben Craftmapper an die OSMF?



Da können Luftbilder schon eine Rolle spielen,
aber "Craftmapping" ist sicherlich nicht das großangelegte Abpinseln
eines Luftbildes in einem Land, dessen Kultur mir fremd ist,


In manchen Fällen, etwa bei dünn besiedelten Gebieten, ist das aber 
wahrscheinlich die beste Möglichkeit, überhaupt eine Karte zu 
produzieren, die mehr als das Straßennetz und seine direkte Umgebung 
enthält. Um etwa Seen, Bäche und Waldumrisse in den schottischen 
Highlands oder in Nordskandinavien einzutragen, braucht man keine 
besonderen Kenntnisse der dortigen Kultur, und die wenigen Mapper, die 
da oben wohnen, sind vermutlich auch nicht böse, wenn sie nicht jedes 
kleine Gewässer selbst eintragen müssen.



und sicherlich auch kein Datenimport


Doch, zum Kartieren "mit allen verfügbaren Mitteln" können auch 
Datenimporte gehören; es haben ja auch schon viele Craftmapper mit viel 
Mühe und wechselndem Erfolg bemüht, z.B. bei ihrer Gemeindeverwaltung 
importierbare Daten zu bekommen. Bei Gemeindegrenzen etwa ist außer 
durch Importe kaum etwas zu machen, aber auch bei irgendwelchen Objekten 
tief im Bergwald ist das vielleicht die realistischste Möglichkeit.



und keine Anwendung von künstlicher
Intelligenz, um auf Luftbildern Straßen erkennen zu können.


Straßen kann ich als Craftmapper natürlich abfahren und habe dann nicht 
nur zuverlässigere Informationen, sondern auch solche, die das Luftbild 
einfach nicht liefert. Wenn es aber eine Anwendung gäbe, die aus einem 
Luftbild einigemaßen zuverlässig automatisch die Hausumrisse herausholt, 
so dass ich das nur noch überprüfen und ggf. korrigieren muss, statt 
Haus für Haus abzupinseln, dann fände ich das als Craftmapper sehr 
erfreulich und würde das auch benutzen. Da vermisse ich einfach 
Projekte, bei denen auch wirklich etwas Bemerkenswertes herausgekommen wäre.



All diese anderen Dinge können auch interessant sein und Spass machen,
aber sie sind in meinen Augen nachrangig. Ich mappe auch gern mal als
"Luftbildtourist" irgendwo in fremden Landen oder schreibe ein Programm,
das irgendwas ändert, aber mir ist dabei klar, dass OSM nie zu dem
geworden wäre, was es heute ist, wenn sowas die normale Herangehensweise
wäre.


Richtig, auf die Vorzüge des Mappens nah am Objekt und mit 
Hintergrundkenntnissen sollte man natürlich hinweisen, wenn die 
neuerdings nicht mehr so bekannt sein sollten. Wobei das Abpinseln von 
coastlines und riverbanks in fernen Landen eigentlich immer auch zur 
normalen Herangehensweise gehört hat.



Das alte Mapping-Handwerk wird aber zusehends mit Füssen getreten. Es
vergeht keine Woche, in der nicht wieder irgendwo jemand jammert, dass
man ohne einen groß angelegten Import ja niemals alle Häuser in Kanada
oder alle Tankestellen in England mappen könnte, weil es viel zu viel
Arbeit sei.


Was die Häuser in Kanada angeht, dürfte das sogar stimmen. Weite Teile 
des Landes sind dünn besiedelt und dazu bewaldet. Auf Luftbildern sieht 
man vieles nicht ("weil Baum" ist hier ausnahmsweise mal eine sinnvolle 
Erklärung), und das weite Land nach der letzten Hütte durchsuchen und 
dann noch deren Umrisse genau einmessen werden die kanadischen 
Craftmapper wohl nicht. Wenn die bezahlten Mapper von den kanadischen 
Katasterämtern uns ihre Ergebnisse zur Verfügung stellen, sollten wir 
die also nutzen. Natürlich mit offenen Augen.



Es beschäftigen sich mittlerweilse Leute beruflich mit
OpenStreetMap, denen nach eigener Aussage ihre Zeit zu schade ist, um
fehlende Daten an ihrem Wohnort zu erfassen; man könne mehr zu OSM
beitragen, heisst es dann, indem man seine anderen Qualitäten in den
Dienst der Sache stellt, als Projektleiter in einem Datenimport-Projekt
oder sonst irgendwas.


Geht es ihnen da um ihre Arbeitszeit (dann stimmt das wahrscheinlich, 
denn fürs Vervollständigen ihres Wohnorts werden sie vermutlich nicht 
bezahlt, während der Import eben für ihren Arbeitgeber nützlich ist), 
oder meinen sie das allgemein?



Ich finde das alles sehr bedauerlich; das Craftmapping ist meiner
Ansicht nach identitätsstiftend für OpenStreetMap. Es ist das, was uns
als Community zusammenhält, worüber wir reden können, wenn wir uns
treffen, es ist das Boot, in dem wir gemeinsam sitzen.


Wobei sich natürlich das Boot über die Jahre immer

Re: [Talk-it] Utente che cancella landuse e crea fiumi

2018-01-05 Per discussione Cascafico Giovanni

La segnalazione al DWG credo sia necessaria: quando l'utente non risponde
agli avvisi di smetterla, é essenziale imporgli la lettura di un messaggio
che gli chiarisca che il suo comportamento sta danneggiando OSM.
Questo si fa con un blocco limitato al tempo di login: finché non legge il
messaggio non può editare.

La richiesta di blocco al DWG magari potrebbe riportare che usa una fonte
decisamente chiusa (IGM).

Il 05/gen/2018 10:24, "Francesco Pelullo"  ha scritto:
>
> Ciao Federico,
>
> ho aggiunto i miei commenti ai changeset indicati da te.
> Hai un approccio molto costruttivo ed accomodante (forse troppo per i
miei standard) :-) mi sono permesso di aggiungere un suggerimento: dagli
delle scadenze entro cui rispondere.
> Se non risponde entro il termine, e magari nel frattempo continua ad
editare, vai di revert senza pensarci troppo.
>
> Ciao
> /niubii/
>
>
>
> Il giorno 5 gennaio 2018 10:01, Federico Cortese 
ha scritto:
>>
>> Carissimi,
>>
>> è con molta ritrosia e titubanza che vi scrivo per segnalare
>> l'ennesimo utente secondo me problematico.
>> Titubanza perchè spesso sembra che segnalare questi problemi sia un
>> atto di scortesia verso i mappatori, che pare debbano essere liberi di
>> esprimersi, facendo perdere molto più tempo a quelli che, oltre a
>> contribuire, vogliono salvaguardare il lavoro proprio e degli altri.
>>
>> A parte questa premessa generale, venendo al caso specifico, questo è
>> l'ultimo changeset col quale sono stati cancellati tutta una serie di
>> poligoni landuse creati da me e da altri:
>>
>> http://nrenner.github.io/achavi/?changeset=55153696
>>
>> Oltre alle cancellazioni, in questo e altri changeset, sono presenti
>> tutti i classici errori di intersezioni geometrie con linee elettriche
>> aeree, fiumi che si sovrappongono a qualunque cosa e tanto altro.
>>
>> Come commentato nel changeset, cerco di contattare l'utente da mesi,
>> sia per messaggi privati, che tramite commenti ai changeset, ma non ho
>> mai ottenuto risposta, almeno per capire che tipo di supporto usa e in
>> base a cosa esegue quelle modifiche, visto che è l'unico ad operare
>> diversamente.
>> Spesso aggiunge source=IGM, ma non so a cosa fa riferimento.
>>
>> Questi altri due esempi di changeset tra i tanti precedentemente
commentati:
>>
>> https://www.openstreetmap.org/changeset/45686107
>> https://www.openstreetmap.org/changeset/54649349
>>
>> Nell'ultimo ha aggiunto tutta una serie di fiumi e riverbank, che
>> forse esistevano centinaia di anni fa, ma di cui oggi non c'è traccia
>> se non quando piove. peppeBA ha trovato la soluzione di sostituire il
>> riverbank con natural=riverbed, ma non so quanto durerà prima che la
>> mappa di quelle zoni torni all'epoca dell'abbondanza d'acqua.
>>
>> Sperando in un vostro supporto, vi ringrazio.
>>
>> Ciao,
>> Federico
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] Statistika využití CZ:IPRPraha:ortofoto

2018-01-05 Per discussione Pavel Zbytovský

Ahoj,

co se týče té statistiky, nejsem si jistý jestli máš započítané i editace z
editoru iD. Přidával jsem obě vrstvy pomocí své TMS-proxy - viz [1][2][3].
Ovšem nevím kdy se to dostalo do main website (a vlastně do JOSMu taky -
layer-index je společný).

Každý kdo v iD změnil libovolnou věc při zapnuté této vrstvě, bude mít v
klíči imagery_used u changesetu buď "IPR ortofoto Low-Vegetation
(tmsproxy)" nebo "IPR ortofoto LAST (tmsproxy)" .. případně oddělené
středníkem.

Myslím ale, že údaje o changesetech v planet.osm nejsou, tudíž by to bylo
potřeba extrahovat je nějak jinak (možná planet i s historií?)

P.

[1] https://github.com/osmlab/editor-layer-index/pull/300
[2] http://osm-a.zby.cz/tiles_ipr_vege.php
[3] http://osm-a.zby.cz/tiles_ipr_last.php .. nějaké rozbité teď


On Fri, Jan 5, 2018 at 4:54 PM Vratislav Filler  wrote:

> Ahoj,
>
>
>
> hojně jsem využíval pro ověření existence či rozsahu cyklopruhů (korekce
> potom, co to tam nejdřív namalujeme od oka), a pro cyklo infra vůbec,
> mimovegetační pro ověření přítomnosti a charakteru cest a chodníků, apod.,
> pro bezmotorovou byly starší ortofoto málo použitelné. Výhodou je i častá
> aktualizace, právě u cykla, kde se stav docela často mění.
>
> Kdyby se někd hecnul, tak podle toho může v Praze udělat předsunuté
> stopčáry.
>
>
>
> V.
>
>
>
> __
> > Od: Jethro 
> > Komu: OpenStreetMap Czech Republic 
> > Datum: 03.01.2018 16:38
> > Předmět: Re: [Talk-cz] Statistika využití CZ:IPRPraha:ortofoto
> >
> Zdar,
> určitě pruhy, prezentovat jako "Zlepšení pro mnohé automobilové
> navigace" ;-) Já jsem jich taky zmapoval docela dost právě podle (a
> díky tomu, že se uvolnily) IPR ortofoto.
> MSF
> Jethro
>
> 2018-01-03 15:47 GMT+01:00 Jan Martinec :
> > Ahoj,
> >
> > to je super, že to aspoň pár lidí využilo.
> > Díky za uznání, ale nějak mě nenapadá jedna velká konkrétní věc, kterou
> jsem
> > s tím dělal - většinou to bylo menší využití v rámci úprav něčeho
> většího -
> > budovy, průchody, vodní toky.
> >
> > Možná pražské mosty - přidával jsem pomocí ortofota pilíře, a zcela
> určitě
> > jsem udělal i spoustu dopravních pruhů (počet, směr, omezení, řazení v
> > nich).
> >
> > Každopádně díky, žes to zařídil - takhle kvalitní podklady kdybychom tak
> > měli všude...
> >
> > Zdar,
> > Honza Piškvor Martinec
> >
> >
> > Dne 3.1.2018 v 14:30 Matej Lieskovský napsal(a):
> >>
> >> Ahoj!
> >>
> >> Jak si možná vzpomínáte, před necelým rokem jsem pomohl získat povolení
> >> k využití ortofotek IPR. Díky tomu nyní máme přístup k snímkům celé
> >> Prahy a okolí, které jsou 2x ročně aktualizovány. V rámci dohody jsem
> >> slíbil počítání statistik. Zatím čekám na zveřejnění nového planet.osm,
> >> ale tady jsou statistiky k 25.12.:
> >>
> >> Data IPR využilo 8 uživatelů ve 396 change setech, které se týkaly 46890
> >> objektů.
> >>
> >> Až budu mít zpracovaná novější data, tak bych jim tohle poslal jako
> >> součást většího reportu.
> >>
> >> Pokud proti tomu nikdo nic nemá, tak bych tam také použil frázi cca typu
> >> "Dovolte, abych Vám jménem české komunity přispěvatelů do OSM
> poděkoval."
> >>
> >> Taky bych tam rád napsal nějaká "pěkná" využití těch fotek. Překreslení
> >> tramvajových tratí bylo z velké části pomocí IPR fotek, já jsem dělal
> >> pár zlepšení porkytí parků (Valdštejná zahrada, Vojanovy sady, Malešický
> >> park, Centrální park, Vyšehrad...), ale vykoukat další věci z těch
> >> changesetů je trochu nad moje možnosti. Víte někdo o něčem, co by se
> >> dalo takhle vypíchnout? Vím, že Piškvor toho taky udělal hodně, ale
> >> zatím nevím, jak to pěkně popsat.
> >>
> >> Ať se daří!
> >>
> >> Matej
> >>
> >> PS: Jo, snažím se dát IPR něco, co zní dobře. Oni to použijí jako
> >> "podívejte se, jak je IPR užitečný" a výměnou za to nám snad do budoucna
> >> dají více dat.
> >>
> >>
> >> ___
> >> Talk-cz mailing list
> >> Talk-cz@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-cz
> >>
> >
> >
> > ___
> > Talk-cz mailing list
> > Talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-es] Cambio de logo para la comunidad OSM en España

2018-01-05 Per discussione Miguel Sevilla-Callejo

Pues ahí va mi propuesta de logo 1.0:
https://imgur.com/4YWPlol

Esta propuesta se basa en el logotipo original de OSM combinando un mapa
del territorio Español* y sin olvidar el código ISO del país, en este caso
"ESP"

A ver que os parece, incluso en tamaños pequeños se ve relativamente bien.

* no se ven las plazas africanas, lo siento, pero si los dos grandes
archipiélagos
* el mapa base es una proyección cónica de Albers para Europa, por eso sale
"inclinado" el territorio

Seguro que le termino de dar alguna otra vuelta otro día...

Un saludo

Miguel

--
*Miguel Sevilla-Callejo*
Doctor en Geografía

2018-01-03 20:28 GMT+01:00 dazer :

> Los cambios de Verdy_p de octubre no tienen absolutamente nada que ver con
> la
> plantilla de país. Ni afecta a qué aparece en la página de España. No
> necesita contar con ningún consenso para modificar lo que viene a ser un
> repositiorio de logos. Se apuntó que es una modificación reciente como
> contraargumento a que la bandera es el logo por defecto.
>
> Como apunta dcapillae, la discusión es sobre la página del país, tras
> decidir quitar el wikiproyect. La cuestión es si queremos usar ese logo que
> está ahí disponible, u otros, para la página del país España.
> Independientemente de la existencia de una comunidad de personas.
>
> La confusión es precisamente la de mezclar comunidad con país. Ciertamente
> la razón por la que este hilo tiene tantas respuestas. Es una cuestión de
> armonizar con el resto del wiki, no de la identidad de la comunidad, o de
> las gentes.
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-it] Utente che cancella landuse e crea fiumi

2018-01-05 Per discussione Andrea Albani

Ciao,
ho commentato il suo ultimo changeset

https://www.openstreetmap.org/changeset/55153819

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

Re: [Talk-cz] Výzva k hlasování - bazény Fell3 - smazat nebo private

2018-01-05 Per discussione Jan Chren (rindeal)

2018-01-05 2:05 GMT+01:00 Miroslav Suchý :

> Budu delat dablova advokata:
>
> Dne 4.1.2018 v 23:24 Jan Chren (rindeal) napsal(a):
> > 1) Spousty tech bazenu je ve skutecnosti nafukovacich nebo se vubec
> > nejedna o bazeny, ale o koi jezirka. -> *Spatna data*
>
> Nafukovaci bazen je bazen. Otazka je jak mapovat, ze tam pres zimu neni.
>

To je pokus o trolling nebo byste snad chtel mapovat i zaparkovana auta?


>
> > 2) Vyber zmapovanych lokalit je evidentne +/- nahodny, a to i v ramci
> > jednotlivych obci. -> *Nekompletni data*
>
> A my mame nekde kompletni data? Ja ve svem okoli mapuji take +- nahodne.
>

V pripade, ze je nekdo ochoten pridavat 5000+ zcela novych objektu, bych
predpokladal systematicnost ala mapathony, kdy se oblast rozdeli na 2D
matici. Nebo alespon kompletnost v ramci vesnice s 500 obyvateli, ale ani
to neni tento pripad. Tento uzivatel pracoval tak, ze do nejake vesnice
pridal 5 bazenu, pak se presunul o 100km dal, tam zmapoval 50 bazenu, atd.
napric celym statem.


>
> > 3) Na vestavene bazeny do 40m2 neni potreba zadne stavebni povoleni,
> > takze o nich nikde nejsou ani zadne zaznamy pro pripadnou kontrolu.
> > Survey bude nekdo asi taky tezko provadet. Pro cteni ze satelitnich
> > snimku je vetsina tech bazenu prilis mala. -> *Tezce ci zcela
> > neoveritelna data*
>
> V mistech kde jsou dobre satelitni mapy to overitelne je.
>

Male soukrome bazenky na necich zahradach jdou spravne zakreslit jen z
ortofotomap. Oblast mapovani daneho uzivatele se vsak malokdy protina s
oblastmi s legalne dostupnymi ortofotomapami.


>
> > 4) A konecne, samotny smysl mapovani je pochybny, protoze se jedna
> > vetsinou o nevyznamne mini stavby u nekoho na zahrade. -> *Zbytecna data*
>
> Co jsou to zbytecna data? Zkusenost me naucila, ze co prijde zbytecne me
> (napr. detaily o zeleznicich) je cenna informace pro jineho.
> Dokazu si predstavit z takovychto dat interpolovat data o spotrebe vody
> pro bazeny v danem regionu.
>

Nelze srovnavat male soukrome bazeny s verejnou zeleznicni siti. A pro
jistotu pripominam, ze proti mapovani spravne otagovanych vestavenych
bazenu dobre viditelnych ze vzduchu/zeme, se tu nikdo nestavi.


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


Shrnul bych to jeste tak, ze se tady jedna o uzivatele, ktery se rozhodl
mapovat ve velkem, mapovat spatne a mapovat z nejasnych zdroju. Proto je
jakykoliv hromadny "fix" ala `access=private` zbytecnym pokusem o
zaplatovani ohromneho osunteleho pytle. Ta data, ktera pridal do databaze
zaroven nejsou nijak vyjimecna, vzacna ci kriticka, a proto neni potreba
usilovat o jejich zachovani na ukor tech chudaku, kteri by to po nem
opravovali. Kazdy muze ty bazeny, ktere stoji za zmapovani, zmapovat znovu
a spravne.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-de] Grenzen und Wege

2018-01-05 Per discussione Christoph Hormann

On Friday 05 January 2018, Toni Erdmann wrote:
> Gute Beispiel!
>
> Wasserläufe ändern sich, die Grenzen in der Regel nicht.

In diesem Beispiel (und auch in den meisten anderen Fällen bei Grenzen 
entlang größerer Wasserläufe) ändert sich die Grenze mit dem 
Wasserlauf.  Im Beispiel ist das durch die Straßenverläufe 
offensichtlich.

-- 
Christoph Hormann
http://www.imagico.de/

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

[OSRM-talk] Does the matching service make use of edge rates?

2018-01-05 Per discussione Nate Wessel


Hi all,

I've recently been playing with the new relation support in profiles, 
trying to get my map-matching results to favour transit routes. For 
testing purposes, I've set rates and speeds on all streets to the same 
value, but multiplied rates on streets with transit routes by 30x. (so I 
should be able to see an effect, right?)


The route service seems to show the effects of this, giving me some 
weird results that clearly follow known transit lines very closely. When 
I use the matching service however, I don't see a similar effect. I have 
a few test cases I'm looking at (GPS traces from transit vehicles) that 
hadn't been matching to their routes properly, but which looked like 
they could with a little nudge. However the map-matching result is 
seemingly unchanged regardless of the way I set rates on edges.


Does the matching service even support custom edge weights? If so, do I 
have to enable this feature somehow, or what else could I be missing?


Thanks,

--
Nate Wessel
Jack of all trades, Master of Geography, PhD Candidate in Urban Planning
SAUSy Lab , Sid Smith Hall, University of Toronto

___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-de] Grenzen und Wege

2018-01-05 Per discussione Samuel Kutter

Es gibt aber Grenzen, die über den Wasserlauf definiert sind (siehe
Beispiel, oder auch Rheingrenze CH-D oder auch viele andere Grenzen der
Welt)

Hier einige Diskussionen im Hilfe-Forum.
https://help.openstreetmap.org/questions/7563/waterway-as-administrative-boundary-shared-way
Ich hatte das zusammengefasst als:
    * Eine geometrische Linie eintragen
    * Als waterway taggen
    * Als Grenze taggen

Also keine zwei geometrische Objekte (ways) (weder separat noch mit
gemeinsamen Nodes), sondern nur ein geometrisches Objekt - sofern die
Grenze über den Fluss definiert ist (was wohl meist der Fall ist).

Samuel



Am 05.01.2018 um 16:46 schrieb Toni Erdmann:
> Gute Beispiel!
>
> Wasserläufe ändern sich, die Grenzen in der Regel nicht.
>
> Toni
>
> Am 05.01.2018 um 16:34 schrieb Christoph Hormann:
>> On Friday 05 January 2018, Martin Scholtes wrote:
>>>
>>> soeben ist mir beim kartieren von Grenzen eine alte Fragestellung
>>> aufgekommen. Wasserwege (Bach/Fluss) markieren oft Grenzen, bzw sind
>>> deckungsgleich mit Grenzen. Sollte ich dann eine Grenzen über den Way
>>> zeichnen oder den Weg mit den bekannten tags füllen und den
>>> jeweiligen Abschnitt dann in die Relation aufnehmen?
>>
>> Das hängt letztendlich davon ab, ob der Wasserlauf die Grenze bildet
>> oder ob die Grenze nur in etwa entlang des Wasserlaufes verläuft.
>>
>> Meiner Erfahrung nach sind mindestens 2/3 der Grenzen in OSM aus
>> vereinfachten oder ungefähr gezeichneten Datensätzen importiert und
>> repräsentieren nicht eine eventuell vorhandene Abmarkung der Grenze so
>> dass die Abweichung zwischen Fluss-Verlauf und Grenz-Verlauf in den
>> Daten vollständig aus Rauschen besteht.  Oft wird aber dennoch der
>> separate Grenz-Verlauf erhalten, denn der stammt ja oft aus einer mehr
>> oder weniger 'offiziellen' Quelle und gilt deshalb als 'korrekt' -
>> selbst wenn das in Wirklichkeit einfach vor zehn Jahren oder so mal von
>> irgendeiner Papierkarte abgezeichnet worden ist.
>>
>> Mein Lieblings-Beispiel ist immer:
>>
>> http://www.openstreetmap.org/#map=15/32.0846/35.5327
>>
>> Für die Mapping-Praxis würd ich sagen: Wenn da Grenzsteine sind und der
>> Grenzverlauf in OSM entspricht diesen weitgehend dann kann und sollte
>> man das separat mappen.  Ansonsten kann man das getrost mit einer
>> Geometrie erfassen.
>>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-cz] Statistika využití CZ:IPRPraha:ortofoto

2018-01-05 Per discussione Vratislav Filler


Ahoj,
 
hojně jsem využíval pro ověření existence či rozsahu cyklopruhů (korekce potom, 
co to tam nejdřív namalujeme od oka), a pro cyklo infra vůbec, mimovegetační 
pro ověření přítomnosti a charakteru cest a chodníků, apod., pro bezmotorovou 
byly starší ortofoto málo použitelné. Výhodou je i častá aktualizace, právě u 
cykla, kde se stav docela často mění. 
Kdyby se někd hecnul, tak podle toho může v Praze udělat předsunuté stopčáry. 
 
V.
 
__

Od: Jethro 
Komu: OpenStreetMap Czech Republic 
Datum: 03.01.2018 16:38
Předmět: Re: [Talk-cz] Statistika využití CZ:IPRPraha:ortofoto


Zdar,
určitě pruhy, prezentovat jako "Zlepšení pro mnohé automobilové
navigace" ;-) Já jsem jich taky zmapoval docela dost právě podle (a
díky tomu, že se uvolnily) IPR ortofoto.
MSF
Jethro

2018-01-03 15:47 GMT+01:00 Jan Martinec :
> Ahoj,
>
> to je super, že to aspoň pár lidí využilo.
> Díky za uznání, ale nějak mě nenapadá jedna velká konkrétní věc, kterou jsem
> s tím dělal - většinou to bylo menší využití v rámci úprav něčeho většího -
> budovy, průchody, vodní toky.
>
> Možná pražské mosty - přidával jsem pomocí ortofota pilíře, a zcela určitě
> jsem udělal i spoustu dopravních pruhů (počet, směr, omezení, řazení v
> nich).
>
> Každopádně díky, žes to zařídil - takhle kvalitní podklady kdybychom tak
> měli všude...
>
> Zdar,
> Honza Piškvor Martinec
>
>
> Dne 3.1.2018 v 14:30 Matej Lieskovský napsal(a):
>>
>> Ahoj!
>>
>> Jak si možná vzpomínáte, před necelým rokem jsem pomohl získat povolení
>> k využití ortofotek IPR. Díky tomu nyní máme přístup k snímkům celé
>> Prahy a okolí, které jsou 2x ročně aktualizovány. V rámci dohody jsem
>> slíbil počítání statistik. Zatím čekám na zveřejnění nového planet.osm,
>> ale tady jsou statistiky k 25.12.:
>>
>> Data IPR využilo 8 uživatelů ve 396 change setech, které se týkaly 46890
>> objektů.
>>
>> Až budu mít zpracovaná novější data, tak bych jim tohle poslal jako
>> součást většího reportu.
>>
>> Pokud proti tomu nikdo nic nemá, tak bych tam také použil frázi cca typu
>> "Dovolte, abych Vám jménem české komunity přispěvatelů do OSM poděkoval."
>>
>> Taky bych tam rád napsal nějaká "pěkná" využití těch fotek. Překreslení
>> tramvajových tratí bylo z velké části pomocí IPR fotek, já jsem dělal
>> pár zlepšení porkytí parků (Valdštejná zahrada, Vojanovy sady, Malešický
>> park, Centrální park, Vyšehrad...), ale vykoukat další věci z těch
>> changesetů je trochu nad moje možnosti. Víte někdo o něčem, co by se
>> dalo takhle vypíchnout? Vím, že Piškvor toho taky udělal hodně, ale
>> zatím nevím, jak to pěkně popsat.
>>
>> Ať se daří!
>>
>> Matej
>>
>> PS: Jo, snažím se dát IPR něco, co zní dobře. Oni to použijí jako
>> "podívejte se, jak je IPR užitečný" a výměnou za to nám snad do budoucna
>> dají více dat.
>>
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz 

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


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


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

Re: [Talk-de] Grenzen und Wege

2018-01-05 Per discussione Toni Erdmann


Gute Beispiel!

Wasserläufe ändern sich, die Grenzen in der Regel nicht.

Toni

Am 05.01.2018 um 16:34 schrieb Christoph Hormann:

On Friday 05 January 2018, Martin Scholtes wrote:


soeben ist mir beim kartieren von Grenzen eine alte Fragestellung
aufgekommen. Wasserwege (Bach/Fluss) markieren oft Grenzen, bzw sind
deckungsgleich mit Grenzen. Sollte ich dann eine Grenzen über den Way
zeichnen oder den Weg mit den bekannten tags füllen und den
jeweiligen Abschnitt dann in die Relation aufnehmen?


Das hängt letztendlich davon ab, ob der Wasserlauf die Grenze bildet
oder ob die Grenze nur in etwa entlang des Wasserlaufes verläuft.

Meiner Erfahrung nach sind mindestens 2/3 der Grenzen in OSM aus
vereinfachten oder ungefähr gezeichneten Datensätzen importiert und
repräsentieren nicht eine eventuell vorhandene Abmarkung der Grenze so
dass die Abweichung zwischen Fluss-Verlauf und Grenz-Verlauf in den
Daten vollständig aus Rauschen besteht.  Oft wird aber dennoch der
separate Grenz-Verlauf erhalten, denn der stammt ja oft aus einer mehr
oder weniger 'offiziellen' Quelle und gilt deshalb als 'korrekt' -
selbst wenn das in Wirklichkeit einfach vor zehn Jahren oder so mal von
irgendeiner Papierkarte abgezeichnet worden ist.

Mein Lieblings-Beispiel ist immer:

http://www.openstreetmap.org/#map=15/32.0846/35.5327

Für die Mapping-Praxis würd ich sagen: Wenn da Grenzsteine sind und der
Grenzverlauf in OSM entspricht diesen weitgehend dann kann und sollte
man das separat mappen.  Ansonsten kann man das getrost mit einer
Geometrie erfassen.



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

Re: [Talk-de] Grenzen und Wege

2018-01-05 Per discussione Christoph Hormann

On Friday 05 January 2018, Martin Scholtes wrote:
>
> soeben ist mir beim kartieren von Grenzen eine alte Fragestellung
> aufgekommen. Wasserwege (Bach/Fluss) markieren oft Grenzen, bzw sind
> deckungsgleich mit Grenzen. Sollte ich dann eine Grenzen über den Way
> zeichnen oder den Weg mit den bekannten tags füllen und den
> jeweiligen Abschnitt dann in die Relation aufnehmen?

Das hängt letztendlich davon ab, ob der Wasserlauf die Grenze bildet 
oder ob die Grenze nur in etwa entlang des Wasserlaufes verläuft.

Meiner Erfahrung nach sind mindestens 2/3 der Grenzen in OSM aus 
vereinfachten oder ungefähr gezeichneten Datensätzen importiert und 
repräsentieren nicht eine eventuell vorhandene Abmarkung der Grenze so 
dass die Abweichung zwischen Fluss-Verlauf und Grenz-Verlauf in den 
Daten vollständig aus Rauschen besteht.  Oft wird aber dennoch der 
separate Grenz-Verlauf erhalten, denn der stammt ja oft aus einer mehr 
oder weniger 'offiziellen' Quelle und gilt deshalb als 'korrekt' - 
selbst wenn das in Wirklichkeit einfach vor zehn Jahren oder so mal von 
irgendeiner Papierkarte abgezeichnet worden ist.

Mein Lieblings-Beispiel ist immer:

http://www.openstreetmap.org/#map=15/32.0846/35.5327

Für die Mapping-Praxis würd ich sagen: Wenn da Grenzsteine sind und der 
Grenzverlauf in OSM entspricht diesen weitgehend dann kann und sollte 
man das separat mappen.  Ansonsten kann man das getrost mit einer 
Geometrie erfassen.

-- 
Christoph Hormann
http://www.imagico.de/

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

[Talk-GB] Mapping accessible toilets and parking

2018-01-05 Per discussione Will Bailey

Hi everyone

I work for a company called Zipabout, based in Oxford. We work in the broad 
space of transport data, partnering with local authorities and transport 
operators in the UK to optimise the transport network.

An area in which we're doing a lot of work is in accessible journey planning 
and real-time wayfinding. By developing our current platform and tailoring it 
to the varying needs of different travellers, we can offer people routes which 
suit them (e.g. via lots of accessible toilets, avoiding stairs or escalators, 
avoiding stations where assistance can't be booked, avoiding very busy services 
etc.) and notify passengers about disruption through personalised communication 
in real time.

Much of the data we use to power our routing service comes from OpenStreetMap; 
this will be where we pull things like accessible toilets and parking data into 
our route planning.

We're currently working on a demonstrator project with the NHS and DfT focusing 
on people living with dementia in North Wales, so that area is my primary focus 
at the moment, but this is something we will eventually provide nationwide, 
appropriate for all sorts of different requirements.

I wanted to ask for an idea of what sort of accessible toilet and blue badge 
parking data (for the UK) is currently in OSM, and, if anyone knows, 
specifically in N. Wales. We're keen to contribute something back to the OSM 
project, so any advice on adding data which is missing would be gladly received.

We also need to map the internal corridors of a number of hospitals in North 
Wales, and I wanted to say that if anyone living in the area would be 
interested in contributing some mapping to help us with this, that would be 
fantastic!

Thanks very much

Will

--
Will Bailey
Research Project Manager
zipabout
Clarendon House, 52 Cornmarket Street, Oxford, OX1 3HJ
www.zipabout.com

This message, its contents and any attachments to it are private, confidential 
and may be the subject of legal privilege. Any unauthorised disclosure, copying 
or distribution of all or part of this message is prohibited. If you are not 
the intended recipient, please notify the sender immediately. ZipAbout Limited 
is a limited liability company registered in England and Wales. Registered No. 
07605147 Registered Office: 303 Ballards Lane, North Finchley, London N12 8NP

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

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

2018-01-05 Per discussione Christian Quest


Le 05/01/2018 à 15:53, Vincent Frison a écrit :
Le 5 janvier 2018 à 12:13, Christian Quest > a écrit :


C'est quelque chose que j'avais exploré pour le rendu FR... avec
les courbes de niveau.

Exemple: https://cl.ly/3u0J2p423J3M

Très joli !

Pour un rendu vraiment propre, il faut appliquer l'ombrage en 2
fois, afin de ne pas trop ombrer certains objets comme les routes.

Il y a de l'ombrage sur certaines zones du rendu HOT, sur les
zones où l'usage est essentiellement lié à une crise et où le
relief est un élément très important. Comme c'est quand même lourd
à gérer, ça n'a pas été généralisé, mais on peut s'y remettre...

Avec plaisir, et d'ailleurs j'aimerais bien aider si possible...

Déjà comprendre le principe du hillshade: sur la ticket github énoncé 
plus haut le gars proposait de récupérer le hillshade depuis 
NaturalEarth 
. 
Mais cela voudrait dire qu'on aurait des tuiles de relief qui seraient 
certes déjà pré-calculés mais avec une résolution très limitée puisque 
leur meilleur dataset est un gros TIFF de 21,600 x 10,800 pixels, ce 
qui fait une résolution de l'ordre de ~2000 mètres.


J'imagine que la vraie solution est plutôt d'avoir les données brutes 
(DEM) en provenance de SRTM1 ou ASTER GDEM dont la résolution native 
est de l'ordre de 30 mètres et qu'elles soit ensuite transformées à la 
volée (avec gdal par ex?) en raster hillshade ?


Ou l'idée est plutôt de réutiliser un service gratuit de tuiles de 
relief comme http://c.tiles.wmflabs.org/hillshading par ex ? J'ai du 
mal à croire que tous les autres services de tuiles OSM ayant du 
relief gênèrent eux même le relief pour les intégrer directement leur 
layer...


Pour une couverture quasi mondiale, le mieux c'est STRMv3, on est à 30m 
et c'est très précis, voire trop... par exemple, j'ai l'ombre de la Tour 
Eiffel ;)


J'avais fait mes tests avec l'EU-DEM qui est aussi à 30m, basé sur 
ASTER+SRTM mais limité à l'Europe.


Il y a pas mal de processing à faire pour obtenir l'ombrage, puis pour 
le rendre transparent afin de l'exploiter directement dans le rendu, 
mais c'est à faire une seule fois et tout s'automatise.


Ensuite il y a la modif de la feuille de style mapnik pour l'intégrer en 
deux passes pour faire un truc propre au final comme l'exemple que j'ai 
donné. Pour quelque chose de propre, il faut les données en local, mais 
rien n'empêche de partager les MNT retraités. Je partage par exemple les 
courbes de niveau calculées sur l'EU-DEM.


--
Christian Quest - OpenStreetMap France

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

Re: [Talk-de] Grenzen und Wege

2018-01-05 Per discussione Martin Scholtes

ok. Aber was wenn doch die Grenze seit jeher dem Flussverlauf folgt?


> Volker Schmidt  hat am 5. Januar 2018 um 16:11 geschrieben:
> 
> Bei Flüssen ist die Sache nicht banal. Oft sind Grenzen an historische 
> Flussverläufe gebunden, die sich möglicherweise verändert haben.
> 
> 2018-01-05 15:38 GMT+01:00 Martin Scholtes  mailto:m...@martin-scholtes.de >:
> 
> > > Hallo zusammen,
> > 
> > soeben ist mir beim kartieren von Grenzen eine alte Fragestellung 
> > aufgekommen.
> > Wasserwege (Bach/Fluss) markieren oft grenzen, bzw sind 
> > deckungsgleich mit Grenzen. Sollte ich dann eine Grenzen über den Way 
> > zeichnen oder den Weg mit den bekannten tags füllen und den jeweiligen 
> > Abschnitt dann in die Relation aufnehmen?
> > 
> > Im Wiki wird empfohlenen zwei getrenne Ways zu erstellen, im Bezug 
> > auf die erleichterte Veränderbarkeit. Um es an einem Beispiel der fest 
> > zumachen. Es geht um folgenden Way: 291649088.
> > 
> > VG Martin
> > __ _
> > Talk-de mailing list
> > Talk-de@openstreetmap.org mailto:Talk-de@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-de 
> > https://lists.openstreetmap.org/listinfo/talk-de
> > 
> > > 
> 
 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Grenzen und Wege

2018-01-05 Per discussione Volker Schmidt

Bei Flüssen ist die Sache nicht banal. Oft sind Grenzen an historische
Flussverläufe gebunden, die sich möglicherweise verändert haben.

2018-01-05 15:38 GMT+01:00 Martin Scholtes :

> Hallo zusammen,
>
> soeben ist mir beim kartieren von Grenzen eine alte Fragestellung
> aufgekommen.
> Wasserwege (Bach/Fluss) markieren oft grenzen, bzw sind deckungsgleich mit
> Grenzen. Sollte ich dann eine Grenzen über den Way zeichnen oder den Weg
> mit den bekannten tags füllen und den jeweiligen Abschnitt dann in die
> Relation aufnehmen?
>
> Im Wiki wird empfohlenen zwei getrenne Ways zu erstellen, im Bezug auf die
> erleichterte Veränderbarkeit. Um es an einem Beispiel der fest zumachen. Es
> geht um folgenden Way: 291649088.
>
> VG Martin
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-cl] Donación de servidor Dell PowerEdge R310

2018-01-05 Per discussione Juan Pizarro

Hola,

hace algunos meses, quizás años, le comente a Julio que tengo un servidor
que quiero donar, tiene poco uso, una año en ambiente de desarrollo.

Me interesa saber si están interesados?

Las características son:

   - 1 224-8312 PER310 Chassis, Up to 4 HP HD w/LCD
   - 1 313-7839 Bezel
   - 1 313-7919 BASEBOARD MANAGEMENT CONTROLLER
   - 1 313-9091 DVD+/-RW, SATA
   - 1 317-2022 Memory for 1CPU Platform
   - 1 317-2025 4GB,2x2GB,1333MHz,2R RDIMM
   - 1 317-2306 X3450,2.66G,4C,8M
   - 1 330-4140 Slide Ready Rail with Cbl Mng Arm
   - 1 330-5113 PWR CRD,120V,10FT,wallplug
   - 1 330-5113 PWR CRD,120V,10FT,wallplug
   - 1 330-5280 DELL MANAGEMENT CONSOLE
   - 1 330-8175 R1,Add-in S6i/H2/H7,2HPHD
   - 1 330-8183 CBL,SAS,6IR,ADPT,HP,HDD
   - 1 330-8207 PowerEdge R310 Heatsink
   - 1 330-8208 Shipping for PowerEdge R310
   - 1 330-8209 PwrSply,Rdnt,400W
   - 1 330-8866 ODD Cable, PowerEdge R310
   - 1 330-8869 Edocs and OpenManage DVD
   - 1 341-8728 500GB,7.2K SATA 3.5 HP
   - 1 341-8728 500GB,7.2K SATA 3.5 HP
   - 1 342-0767 SAS 6iR SAS internal RAID adapter
   - 1 420-6320 NO OPERATING SYSTEM
   - 1 430-2008 ONBD DUAL NTWRK ADPTR
   - 1 909-7897 HW WRTY + SVC,PER310,UNY,INIT,LA
   - 1 928-4570 BASIC NBD OS,PER310,UNY,INIT,LA
   - 1 909-7858 HW WRTY,PER310,UNY,EXT,LA
   - 1 925-7432 BASIC NBD OS,PER310,UNY,2YR EXT,LA
   - 1 909-7917 NBD,PER310,DECLINED PRO SPT,LA
   - 1 911-0418 ONSITE INSTL DECLINED LA/BZ
   - 1 917-7479 INFO, BASIC SPT 1YR SATA HDD, LA


Saludos

-- 

*Juan Pizarro*
*E-Mail:*
*Twitter: *
*LinkedIn: *
jpizar...@gmail.com
@jpizarrom 
jpizarrom 

-
OpenStreetMap.cl: El Mapa Libre del Mundo
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

Re: [Talk-cz] petr1868: data znicena LPIS importem na Zernovce

2018-01-05 Per discussione Zdeněk Pražák

no pokud to mohu posoudit podle IPR Ortofota tak jsem to opravil

Dne 5. ledna 2018 12:28 Pavel Machek  napsal(a):

> Ahoj!
>
> Preplacnout LPISem existujici data neni vzdy dobry napad. Viz nesmysl
> ktery vznikl na
>
> http://www.openstreetmap.org/#map=19/50.00352/14.74784
>
> Autora muzu ujistit ze takhle to tam opravdu nevypada, kdyby to
> nahodou nebylo jasne; puvodni data odpovidala.
>
> Mohl by petr1868 opravit zpusobene skody podle puvodnich dat, ja pak
> docistim zbytek?
>
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.
> cz/~pavel/picture/horses/blog.html
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

2018-01-05 Per discussione Vincent Frison

Le 5 janvier 2018 à 12:13, Christian Quest  a
écrit :

> C'est quelque chose que j'avais exploré pour le rendu FR... avec les
> courbes de niveau.
>
> Exemple: https://cl.ly/3u0J2p423J3M
>
Très joli !

> Pour un rendu vraiment propre, il faut appliquer l'ombrage en 2 fois, afin
> de ne pas trop ombrer certains objets comme les routes.
>
> Il y a de l'ombrage sur certaines zones du rendu HOT, sur les zones où
> l'usage est essentiellement lié à une crise et où le relief est un élément
> très important. Comme c'est quand même lourd à gérer, ça n'a pas été
> généralisé, mais on peut s'y remettre...
>
Avec plaisir, et d'ailleurs j'aimerais bien aider si possible...

Déjà comprendre le principe du hillshade: sur la ticket github énoncé plus
haut le gars proposait de récupérer le hillshade depuis NaturalEarth
.
Mais cela voudrait dire qu'on aurait des tuiles de relief qui seraient
certes déjà pré-calculés mais avec une résolution très limitée puisque leur
meilleur dataset est un gros TIFF de 21,600 x 10,800 pixels, ce qui fait
une résolution de l'ordre de ~2000 mètres.

J'imagine que la vraie solution est plutôt d'avoir les données brutes (DEM)
en provenance de SRTM1 ou ASTER GDEM dont la résolution native est de
l'ordre de 30 mètres et qu'elles soit ensuite transformées à la volée (avec
gdal par ex?) en raster hillshade ?

Ou l'idée est plutôt de réutiliser un service gratuit de tuiles de relief
comme http://c.tiles.wmflabs.org/hillshading par ex ? J'ai du mal à croire
que tous les autres services de tuiles OSM ayant du relief gênèrent eux
même le relief pour les intégrer directement leur layer...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cz] Rozcestníky bez tagu operator

2018-01-05 Per discussione Miroslav Suchy

Dne 5.1.2018 v 15:36 majka napsal(a):
> Ten regularni vyraz v tom puvodnim overpass dotazu jsem upravil na:
> ^[A-Z]{2}[0-9]{3}$
> a uz vypadlo "jen" 1105 rozcestniku.

^(.*;)*[a-zA-Z]{2}[0-9]{3}(;.*)*$

1158 rozcestniku

Pro majku: cokoliv pred strednikem (volitelne). Dve pismena. Tri cislice. A 
opet volitelne strednik a cokoliv za nim.

Mirek

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

Re: [OSM-talk-fr] Problème IPv6 chez Orange causant des erreurs avec JOSM

2018-01-05 Per discussione Vincent Bergeot


Bonjour


Le 04/01/2018 à 20:02, Vincent Privat a écrit :
Le workaround pour ce problème est de positionner à "false" la 
propriété "prefer.ipv6" dans les options avancées de JOSM.


je confirme que cela fonctionne, merci beaucoup !!!

Bonne journée

Vincent

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

Re: [Talk-de] Craftmapping

2018-01-05 Per discussione Norbert Kück


Hallo,

am 04.01.2018 um 15:39 schrieb Frederik Ramm:

[...] "Craftmapping" (zu deutsch: "handwerkliches Kartieren"?) ist in
meinen Augen die traditionelle OpenStreetMap-Arbeit: eine Gegend, die
man selber kennt, mit allen verfügbaren Mitteln (vorallem mit
Ortsbegehung) auf die Karte zu bringen. Da können Luftbilder schon
eine Rolle spielen,[...]
Der Beitrag tut richtig gut. Ich bevorzuge handwerkliches Kartieren und 
verwende unterstützend andere Quellen - allerdings nicht mechanisiert.
Ein Ground-Truth-Dogma halte ich für verfehlt. OSM ist eine 
georeferenzierte Faktendatenbank, die glücklicherweise sehr viel mehr 
Informationen hält, als man im Gelände wahrnehmen kann. Und nicht alles, 
was man im Gelände sieht, ist wahr. Vernunft geht vor Schema.

Gruß
Norbert (übrigens OSMF-Mitglied)

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

[Talk-de] Grenzen und Wege

2018-01-05 Per discussione Martin Scholtes

Hallo zusammen,

soeben ist mir beim kartieren von Grenzen eine alte Fragestellung aufgekommen.
Wasserwege (Bach/Fluss) markieren oft grenzen, bzw sind deckungsgleich mit 
Grenzen. Sollte ich dann eine Grenzen über den Way zeichnen oder den Weg mit 
den bekannten tags füllen und den jeweiligen Abschnitt dann in die Relation 
aufnehmen?

Im Wiki wird empfohlenen zwei getrenne Ways zu erstellen, im Bezug auf die 
erleichterte Veränderbarkeit. Um es an einem Beispiel der fest zumachen. Es 
geht um folgenden Way: 291649088.

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

Re: [Talk-cz] Rozcestníky bez tagu operator

2018-01-05 Per discussione majka

Ještě to ručně proberu, zas tak automatické úpravy to nejsou :)

2018-01-05 15:36 GMT+01:00 Tomas Novotny :

> On Fri, 5 Jan 2018 15:29:07 +0100
> Tomas Novotny  wrote:
>
> > Ten regularni vyraz v tom puvodnim overpass dotazu jsem upravil na:
> > ^[A-Z]{2}[0-9]{3}$
>
> no, tak tento regularni vyraz vyhodil i refy typu xx000 (mala pismena) a
> pak
> jeste ŠU000 (jsou u Sumperku), coz neni uplne idealni. Pri letmem
> proklikani
> je jen v Krkonosich jeden rozcestnik, ktery ma ref z deviti cisel.
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Rozcestníky bez tagu operator

2018-01-05 Per discussione majka

Díky za úpravu toho dotazu, obojí (regex i overpass turbo) se učím stylem
což takhle zkusit ještě tohle...
Takže ještě hromadně doplním i tohle, budou toho další 3 sady změn.

2018-01-05 15:29 GMT+01:00 Tomas Novotny :

> Ten regularni vyraz v tom puvodnim overpass dotazu jsem upravil na:
> ^[A-Z]{2}[0-9]{3}$
> a uz vypadlo "jen" 1105 rozcestniku.
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Rozcestníky bez tagu operator

2018-01-05 Per discussione Tomas Novotny

On Fri, 5 Jan 2018 15:29:07 +0100
Tomas Novotny  wrote:

> Ten regularni vyraz v tom puvodnim overpass dotazu jsem upravil na:
> ^[A-Z]{2}[0-9]{3}$

no, tak tento regularni vyraz vyhodil i refy typu xx000 (mala pismena) a pak
jeste ŠU000 (jsou u Sumperku), coz neni uplne idealni. Pri letmem proklikani
je jen v Krkonosich jeden rozcestnik, ktery ma ref z deviti cisel.

T.

> a uz vypadlo "jen" 1105 rozcestniku.
> 
> Nasel jsem tam i svuj rozcestnik, kde jsem evidentne na operatora zapomnel.
> 
> T.
> 
> On Fri, 5 Jan 2018 15:23:34 +0100
> "o...@kub.cz"  wrote:
> 
> > Ověřil bych že je to ve tvaru XX000 a doplnil.
> > 
> > 
> > On 5.1.2018 15:20, majka wrote:  
> > > Tagy operator u rozcestníků jsou sjednocené.
> > >
> > > Máme ale 1157 turistických rozcestníků 
> > >  zcela bez tohoto tagu, které mají 
> > > pětimístný tag ref, tedy s největší pravděpodobností rozcestníky KČT 
> > > ve formátu CB001. Doplnit tag operator nebo ne?
> > >
> > >
> > > ___
> > > Talk-cz mailing list
> > > Talk-cz@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-cz
> >   
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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

Re: [Talk-cz] Výzva k hlasování - bazény Fell3 - smazat nebo private

2018-01-05 Per discussione o...@kub.cz


Za mě je má dva jednoduchý body

 * Pokud jsou to licenčně vadná data pak smazat.

 * Pokud nejsou vadná, tak nemezat tak access=private. Bazény na
   zahradách občas taky mapuju a je to dobrý orientační bod, ale
   access=private je zásadní pro ten usecase - jdeme se koupat, koukni
   na mapu kam.

a jeden méně jasný

 * pokud není jasné jestli jsou nebo nejsou a expertní odhad majky říká
   že jsou, tak smazat.

o těch prvních dvou jsem ale přesvědčen.




On 5.1.2018 13:31, majka wrote:

Dovolím si reagovat za sebe:

- vadí to, že je toho spousty a konkrétní zdroj nebyl uveden ani po 
několika přímých dotazech (pokud nám proběhnou jednotlivosti, není to 
takový problém)


- pochybný zdroj: na kompatibilních mapách se to v době, kdy to fell3 
mapoval, najít nedalo. Vidět to bylo buď z ortofota katastru, mapy.cz 
 nebo google (hlavně to ortofoto katastru, které mimo 
Prahu přece nelze používat). Nic z toho není podklad pro mapování. 
Konkrétní případy se tu probíraly loni.

Kde jinde to sebral když to neřekne?
pozn: fotí/fotil pro Mapillary, ale z toho nenamapuje 100% polohu 
bazénu na zahradě domu / cestu za plotem, kam podle jeho vlastních 
fotek není vidět z ulice. Obojí je samozřejmě v OSM bez omezení přístupu.


- nekompletní/chybná data: většinou (odhaduji víc jak 95% jsou to 
soukromé bazény na zahradách domů), tedy to access=private chybí


O užitečnosti těch dat se bavit nehodlám. Uživatele fell3 se mi 
patrně podařilo urazit, i když nechtěně, takže od 8.11. na OSM nesáhl. 
Původně jsme se s ním přece chtěli jen a pouze domluvit a DOČASNĚ 
zastavit či zpomalit jeho mapování, které se spíš zdálo bezhlavým 
hrnutím dat do databáze.


2018-01-05 12:54 GMT+01:00 Karel Volný >:



a jinak, jak už jsem nadhodil v odpovědi na úvodní mail, pokud
někdo píše o
"spoustách" a "většině", která je 'špatná' nebo 'neověřitelná',
chtělo by to
konkrétní příklady - moje pozorování je s takovými tvrzeními v příkrém
rozporu; ale jak jsem řekl, viděl jsem malý vzoreček, na základě
kterého bych
si nedovolil takto kvantifikovat ...

K.





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


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

[Talk-cz] Rozcestníky bez tagu operator

2018-01-05 Per discussione majka

Tagy operator u rozcestníků jsou sjednocené.

Máme ale 1157 turistických rozcestníků 
zcela bez tohoto tagu, které mají pětimístný tag ref, tedy s největší
pravděpodobností rozcestníky KČT ve formátu CB001. Doplnit tag operator
nebo ne?
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Rozcestníky bez tagu operator

2018-01-05 Per discussione Tomas Novotny

Ten regularni vyraz v tom puvodnim overpass dotazu jsem upravil na:
^[A-Z]{2}[0-9]{3}$
a uz vypadlo "jen" 1105 rozcestniku.

Nasel jsem tam i svuj rozcestnik, kde jsem evidentne na operatora zapomnel.

T.

On Fri, 5 Jan 2018 15:23:34 +0100
"o...@kub.cz"  wrote:

> Ověřil bych že je to ve tvaru XX000 a doplnil.
> 
> 
> On 5.1.2018 15:20, majka wrote:
> > Tagy operator u rozcestníků jsou sjednocené.
> >
> > Máme ale 1157 turistických rozcestníků 
> >  zcela bez tohoto tagu, které mají 
> > pětimístný tag ref, tedy s největší pravděpodobností rozcestníky KČT 
> > ve formátu CB001. Doplnit tag operator nebo ne?
> >
> >
> > ___
> > Talk-cz mailing list
> > Talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz  
> 

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

Re: [Talk-cz] Rozcestníky bez tagu operator

2018-01-05 Per discussione o...@kub.cz


Ověřil bych že je to ve tvaru XX000 a doplnil.


On 5.1.2018 15:20, majka wrote:

Tagy operator u rozcestníků jsou sjednocené.

Máme ale 1157 turistických rozcestníků 
 zcela bez tohoto tagu, které mají 
pětimístný tag ref, tedy s největší pravděpodobností rozcestníky KČT 
ve formátu CB001. Doplnit tag operator nebo ne?



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


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

[Talk-cat] Mapa d'errors simples

2018-01-05 Per discussione Joan Montané

Hola,

com que el grup de Telegram té molta activitat i costa molt trobar-hi les
coses, compleixo el meu compromís i envio aquest correu per a "documentar"
una mica la idea que aquesta dies he comentat al grup: un mapa autònim on
visualitzar errors "fàcils de detectar".

Aquí [1] teniu una prova de concepte. És un mapa amb dues capes. En una es
mostren les vies que comencen per tipus de via en castellà, i l'altra són
noms que possiblement tinguin una L·L mal escrita/codificada. L'àrea de les
consultes és Andorra, Principat, Illes Balears. He exclòs el País Valencià
perquè apareixen molts ressultats i el Leaflet penja el navegador.

El pop-up està pensat per a errors relacionats amb el nom, però es podrien
crear altres tipus de pop-up si fós necessari.

El codi html que es mostra a [1] és aquí [3]. Idealment el mapa no hauria
de tenir cap marcador. (tot el codi font és a [2], he de fer-hi neteja).

Per a mostrar el capes, tenim un array amb les dades de cada capa [4] i les
geojson que obtenim amb overpass-turbo [5].

Per a canviar el mapa només cal canviar l'array i els fitxer geojson
associats. Això ho tinc automatitzat amb un script [6]. L'script és molt
cutre, i no fa cap control, però bàsicament actualitza l'array i els
geojson del mapa, a partir d'un csv. També posa la data i hora de quan s'ha
generat el mapa. Així doncs, amb aquest script es podria mantenir el mapa
actualitzat cada X hores.

En fi, com comentava per Telegram, no és un Osmose, però sí que un mapa
així ens permetria visualitzar petits errors que són fàcils de detectar.

Comentaris?

Salutacions,
Joan Montané

[1] https://gent.softcatala.org/jmontane/coses/osm/
[2] https://github.com/OSM-Catalan/simple-errors-map
[3] https://github.com/OSM-Catalan/simple-errors-map/tree/master/html
[4]
https://github.com/OSM-Catalan/simple-errors-map/blob/master/html/js/osm-ca.js#L17
[5]
https://github.com/OSM-Catalan/simple-errors-map/tree/master/html/geojson
___
Talk-cat mailing list
Talk-cat@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cat

Re: [Talk-cz] Správný operator u rozcestníků

2018-01-05 Per discussione Václav Kroupar

Já to napsal blbě. Myslel jsem, zda kromě relací mám též doplnit kct_barva
(kct_red=major, kct_green=local, kct_learning...)?
Díky Vašek
-- Původní e-mail --
Od: Marián Kyral 
Komu: OpenStreetMap Czech Republic 
Datum: 5. 1. 2018 12:24:40
Předmět: Re: [Talk-cz] Správný operator u rozcestníků
"Ahoj,
omlouvám, jestli byla "přednáška" zmatečná. Celé se to točilo okolo
používání značky kct_barva (kct_red=major, kct_green=local, kct_learning...)
Na tag operator=* to nemá vliv. Takže se stále používá operator=cz:KČT
(pokud trasu spravuje KČT).

Už bych se konečně někdy mohl dokopat k tomu, to na wiki aktualizovat :-(

Marián

-- Původní e-mail --
Od: Václav Kroupar 
Komu: OpenStreetMap Czech Republic 
Datum: 5. 1. 2018 12:01:07
Předmět: Re: [Talk-cz] Správný operator u rozcestníků
"Poslechl jsem si přednášky z OpenAlt. Jestli jsem to dobře pochopil, tak
bych u turistických tras měl používat jak relace, tak cz:KČT. Zatím jsem
dával jen relace v domnění, že KČT je historie.
Je-li KČT potřeba, tak tagy doplním. Dají se v iD najít všechny mé změny?
Vašek
-- Původní e-mail --
Od: Petr Schönmann 
Komu: OpenStreetMap Czech Republic 
Datum: 5. 1. 2018 10:36:52
Předmět: Re: [Talk-cz] Správný operator u rozcestníků
"Na dlouhé zimní večery -
http://taginfo.openstreetmap.cz/search?q=K%C4%8CT#values můžete
opravovat KČT related věci

Dne 5. ledna 2018 9:59 majka  napsal(a):
> Už se na tom dělá, rozcestníky zrovna postupně nahrávám. Dělám každou
změnu
> zvlášť, těch KČT -> cz:KČT bude několik sad (po 500 rozcestnících). Ty ČKT
a
> varianty taky projdu.
>
> 2018-01-05 9:48 GMT+01:00 Milan Cerny :
>>
>> Také souhlasím, sjednocení by bylo dobré.
>> Ještě bych do seznamu přidal překlep"cz:ČKT" 113x
>>
>> Milan
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>

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

Re: [Talk-cz] Výzva k hlasování - bazény Fell3 - smazat nebo private

2018-01-05 Per discussione jozka

S dovolenim jen nektere veci, doufam, ze kontext zustane.

>- přinejmenším by bylo vhodné vysvětlit, proč by takové pravidlo mělo platit, 
>a za jakých okolností ... jinak tedy, když už argumentujeme ad absurdum jako s 
>těmi dětskými stany, bychom mohli říci, že třeba takové hranice také nijak 
>spojené se zemí nejsou, v reálu takové čáry prakticky vůbec neexistují, tak 
>pojďme smazat z mapy hranice ...

Zkus si nekde vykopat hranicni meznik (vtip...)
Mel jsem za to, ze se bavime o objektech, budovach, technologiich, 
komunikacich... ne o spravnich hranicich (napriklad).


>na jednu stranu fajn, že z tebe mluví zkušenost, na druhou stranu potřeby a 
>postupy v komerční sféře se dosti často a dosti často zásadně liší od potřeb v 
>hobby projektech (že tyto pak mohou být komerčně vy/zne-užity je věc jiná) - 
>kdyby byli zakladatelé OSM spokojeni s nabídkou od těch, co se tím živí, 
>zjevně by OSM vůbec nevznikla, že
>

On to neni pristup komercni sfery, kdyz se daval dohromady ZABAGED, delal jsem 
jeden den "domorodeho pruvodce" chlapkovi z katastru. Prijel s leteckou fotkou, 
chodili jsme po arealu a on nemilosrdne vyskrtaval vsechno, co bylo 
kontejnerem, bunkou, odlozenou technologii a podobne. Prave podle te 
pravdepodobnosti toho, co tam bude za rok. Zitra tady totiz muze byt krater a 
ne krajina. Ale pravdepodobnost, ze tam zitra bude Trojska lavka je o neco 
vyssi, nez ze tam bude ta maringotka (a presto to nevyslo, to je ta mrcha 
pravdepodobnost). Kdyz to zjednodusim do absurdna, "minimum prostredku na 
maximum uzitku". Za tech vic nez dvacet let uz jsem byl nejednou svedkem toho 
jak nekdo navrhne super postup a system jak zmapovat kde co, jen uz trochu 
nedomyslel jako k tem datum prijit a hlavne (a to je i tenhle pripad), jak je 
udrzet alespon trochu relevatni. Takze ano nechme tam bazeny. Ale smirme se s 
tim, ze uz ted je to tezce neaktualni, protoze je leden a vetsina tech bazenu 
je sro
 lovana v
  kulnach. Nektere pujdou v kvetnu ven na to same misto, nektere jinam a 
nektere vubec. Kdo se hlasi, ze to projde?

Aby bylo jasno, jen jsem spitl svou zkusenost, to jestli bude brana v potaz ci 
nikoli mne pri patku nerozhodi, na to uz jsem podobnych "stretu" prosel moc :-)

Ahoj
J.

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

Re: [Talk-it] disused:

...strano che non interessi quasi a nessuno questo argomento

chiedo scusa ma voi utilizzate disused=yes o il prefisso disused:  ??

guardando taginfo ed anche in base ad alcune query mirate su alcuni tags io
ho l'impressione che sia normalmente ancora largamente (e quasi sempre)
utilizzato disused=yes ed in maniera molto ma molto minore il prefisso
disused: ma magari mi sbaglio...

grazie, ciao

--enrico




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

[OSM-talk-fr] adresses en France et StreetComplete [dérivé de Re: schéma des addr]

2018-01-05 Per discussione althio

Il me semble que l'auteur de StreetComplete (application Android de
collecte et contribution) aurait besoin d'information sur les
pratiques "adresses" en France... de manière à décider si son
application devrait ou ne devrait pas proposer des modifications
concernant les adresses en France.

Voir (et intervenir ?) sur
https://github.com/westnordost/StreetComplete/issues/714#issuecomment-353980856

Vos avis ?

-- althio


2018-01-05 14:04 GMT+01:00 Christian Quest :
> Marc, tu te trompe sur plusieurs points.
>
> contact:* est documenté et l'était bien avant qu'on en parle ici. Il s'agit
> bien d'indiquer pour un POI le moyen de le contacter, pas que via son
> adresse. Séparer la définition de l'adresse et celle du POI est assez
> logique.
>
> Les deux schémas utilisé pour modéliser les adresses sont largement
> utilisables, que ce soit avec les relations ou sans.
>
> On peut tout à fait relancer la discussion, mais comme les éléments de
> départs n'ont pas changé, je ne vois pas pourquoi on arriverait à une autre
> conclusion.
>
>
> Il ne faut pas tout mélanger. Là, le départ c'est une anomalie signalée à
> juste titre par osmose (si j'ai bien suivi) avec des modifications faites à
> moitié.
>
>
> Les adresses ça semble simple, mais en même temps c'est complexe, ce que
> j'ai découvert en bossant ces dernières années sur le sujet. Pour beaucoup
> de monde il y a confusion entre adresse et bâtiment (d'où cette tendance à
> mettre des adresses sur les polygones de bâtiments) alors que non, ça n'est
> pas du 1 vers 1.
>
> J'ai encore dû expliquer à un dev ce matin qui réalisait un écran de saisie
> d'adresse sur une borne que non, les codes postaux ne correspondent pas à
> une commune... qu'il y a environ 6000 codes postaux et plus de 35000
> communes (CQFD).
>
> Peut être devrions nous mieux expliciter tout ça sur le wiki pour bien faire
> comprendre la logique des adresses, ce qu'elles sont et ne sont pas, etc.
>
>
>
> Le 5 janvier 2018 à 13:15, marc marc  a écrit :
>>
>> Le 04. 01. 18 à 23:53, osm.sanspourr...@spamgourmet.com a écrit :
>> > une personne a vire le addr:housenumber parce que trop près de la
>> > voirie.
>> > http://www.openstreetmap.org/changeset/35942339
>>
>> le problème est plus large que cela.
>> ce qu'on peux lui reprocher :
>> ses modifs sont incohérente avec le reste de la rue.
>> s'il voulait migrer le nœud addr au profit du bâtiment, il fallait le
>> faire au complet = supprimer totalement ce nœud et remplacer le noeud
>> par le bâtiment dans la relation assosciatedStreet
>> Et idéalement faire toute la rue en une fois pour garder une micro
>> cohérence toute symbolique et absurde que cela soie dans ce cas.
>>
>> L'autre problème, c'est qu'en mettant le nœud quelque part en bordure de
>> la parcelle, on confie au hasard le lien entre une adresse et un bâtiment.
>> Si on veux tager le fait que c'est la parcelle qui a une adresse et non
>> le bâtiment, soyons cohérent de taguer la parcelle (ce qui est hors de
>> portée du contributeur moyen).
>> Mais un tag de nœud mis positionné sans règle précise, c'est la foire.
>> Dans ton lien, il est par exemple impossible de savoir avec certitude
>> l'adresse du bâtiment au sud de la rue du Muguet
>> https://www.openstreetmap.org/node/2045090782#map=19/48.37680/-4.57899
>> peut-être est-ce le 27 à moins que le bâtiment de gauche aie 3 adresses
>> et que celui du bas n'ai pas encore d'adresse renseignée.
>> peut-être même que c'est le 19 Route de Trénen avec une allée privée non
>> renseigne. bref, faut prendre une vue satellite pour essayer de deviner
>> l'adresse
>> La solution de rapprocher le nœud du bâtiment revient implicitement à
>> dire qu'on considère qu'il y a un lien entre l'adresse et le bâtiment
>> tout en étant incohérent dans le fait de ne pas tager ce lien.
>>
>> Par conséquent, il ne faut pas s'étonner que des contributeurs finissent
>> par ajouter les adresses sur les bâtiments lorsque ceux-ci n'ont qu'une
>> adresse ou sur les portes d'entrée.
>> Et on a le même problème avec ceux qui placent les poi à l'entrée de la
>> parcelle (vu hier le cas hier d'un nœud en bord de route pour désigner
>> la présence d'une chambre d'hôte dans un bâtiment des environs)
>> aucun lien avec le bâtiment ni son adresse.. donc les gens finissent
>> par encoder l'adresse une 3ieme fois.
>> certains pensent que ce problème s'évite en utilisant une xieme
>> spécificité franco-francaise des contact:addr documenté nulle part et
>> donc utilisé par aucune app.
>>
>> Perso je suis triste de voir toutes ces infos inutilisable dans une
>> appli simplement par manque de schéma cohérent.
>> J'avais proposé qu'on s'attaque l'an passé à ce dossier difficile
>> mais pour le moment, la seule chose sur laquelle on est d'accord,
>> c'est le fait qu'on n'est pas d'accord.
>> peut-être pourrait-on faire un pas en voyant s'il y a au moins un accord
>> pour ouvrir ce chantier, chacun pourrait dire les problèmes

Re: [OSM-talk-fr] schéma des addr

2018-01-05 Per discussione Axelos

Le 05/01/2018 à 14:04, Christian Quest a écrit :
> Peut être devrions nous mieux expliciter tout ça sur le wiki pour bien
> faire comprendre la logique des adresses, ce qu'elles sont et ne sont pas,
> etc.


En effet, ce serait vraiment une très bonne idée, car c'est vraiment
très complexe à comprendre l'ensemble. Comme l'a écrit Marc, il n'y a
pas d'explication de l'usage de contact:* au lieu de addr:* pour les
POI. C'est quasi impossible de comprendre sans demander sur cette liste,
forum, etc. (d’où le sujet qui revient souvent).

D'ailleurs JOSM ne propose ce type de balise pour les POI, et j'imagine
que les éditeurs en ligne non plus.

À plus.

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

Re: [OSM-talk-fr] schéma des addr

Pourquoi ne pas utiliser la localisation du nœud venant du cadastre (quand
il y est indiqué) ou d'un SIG open data local? C'est un bon compromis,
souvent déjà en bordure de parcelle, et pas lié aux exigences de la poste
pour le placement des boites aux lettres souvent déplacées loin du lieu et
regroupées en zones rurale parfois sur une autre rue/route.

Ce nœud en revanche ne doit pas être sur la surface de la voirie publique,
on est d'accord. Le placement normal c'est sur l'intersection entre la voie
d'accès menant de la voirie publique à la porte du bâtiment (ou son parking
privé) et limite entre la parcelle privée et la voirie publique. Il n'y a
pas obligation que ce soit sur le bâtiment, ce peut être au niveau d'un
portail, d'une clôture. C'est le placement le plus pratique. Il n'y a qu'en
milieu urbain dense (quand les bâtiments bordent les trottoirs que le
placement le long du mur du bâtiment (faisant office de limite de parcelle)
est approprié et il est préférable de placer le nœud là qu'au milieu du
bâtiment qui peut avoir plusieurs façades exposées à différentes voiries
(et parfois deux adresses ou plus pour le même bâtiment même s'il n'y a
qu'un seul accès: dans ce cas on les réparti au plus proche si on peut les
distinguer, sinon on indique un groupe de numéros comme "10-12" si on ne
peut plus les distinguer parce que le bâtiment actuel a remplacé deux
anciens à accès séparés)

Note: on a bien des cas avec des bâtiments ayant plusieurs adresses sur des
rues différentes et pour le même accès, pour le courrier un seul est
utilisé mais certaines adresses postales mentionnent les deux simultanément
(mais le cadastre fait encore les distinctions). Et pas seulement en France
!

(le Royaume-Uni recense des tonnes de cas compliqués, mais en international
on a des cas encore plus "tordus" sur les adresses, comme au Japon
(structure complètement différente) ou au Nicaragua (l'adresse est une
forme abrégée d'itinéraire à suivre et de distances, depuis un point de
référence qui parfois n'existe plus, ainsi que des directions vers des
objets invisibles depuis le point de départ comme le nom d'une forêt ou
d'un lac où on ne passera même pas et qui ne figure même pas sur les cartes
car c'est aussi un ancien nom, ainsi qu'un vocabulaire particulier pour les
directions à suivre, et même des unités de mesure spécifiques pour les
distances ou temps de parcours à pied alors que le cheminement à pied n'est
plus le même, des couleurs de murs qui ont pu changer, d'anciens arbres,
fontaines, ou monuments notables disparus  !) ; et encore plus compliqué en
Afrique centrale ou en Afghanistan (repérage incluant des descriptions
physiques, des noms de personnes ou de métiers qui ont pu aussi
disparaitre...) mais là il n'y a aucun formalisme pour codifier ça de façon
homogène (et cela nécessite une connaissance personnelle locale et de la
diplomatie avec les habitants pour demander le chemin à suivre et trouver
les bonnes personnes qui connaissent : un vrai jeu de piste !)

Cela arrive suite à des travaux d'aménagement ou opérations immobilières,
où plusieurs anciennes propriétés fusionnent en copropriété (voire une
propriété unique) pour partager des parties communes (garages/caves,
jardin/cour, local poubelle, locaux de services pour le chauffage ou les
réseaux, gardiennage), ou créer une partie privée sur une partie des
plusieurs bâtiments jointifs (aménagements de commerces ou bureaux) ou
mieux sécuriser leurs accès et faciliter la navigation intérieure
(escaliers dans un bâtiment, mais ascenseur dans le voisin, issues de
secours accessibles des deux cotés, et ouverture de passages entre
bâtiments dans les étages, mais une seule porte commune conservée et
regroupement des boites à lettres sur un seul palier commun, l'autre ancien
palier pouvant redevenir privatif, suppression d'anciens escaliers peu
pratiques pour gagner de la place habitable dans un des bâtiments et en
confort pour tous les occupants).

Le 5 janvier 2018 à 13:15, marc marc  a écrit :

> Le 04. 01. 18 à 23:53, osm.sanspourr...@spamgourmet.com a écrit :
> > une personne a vire le addr:housenumber parce que trop près de la
> > voirie.
> > http://www.openstreetmap.org/changeset/35942339
>
> le problème est plus large que cela.
> ce qu'on peux lui reprocher :
> ses modifs sont incohérente avec le reste de la rue.
> s'il voulait migrer le nœud addr au profit du bâtiment, il fallait le
> faire au complet = supprimer totalement ce nœud et remplacer le noeud
> par le bâtiment dans la relation assosciatedStreet
> Et idéalement faire toute la rue en une fois pour garder une micro
> cohérence toute symbolique et absurde que cela soie dans ce cas.
>
> L'autre problème, c'est qu'en mettant le nœud quelque part en bordure de
> la parcelle, on confie au hasard le lien entre une adresse et un bâtiment.
> Si on veux tager le fait que c'est la parcelle qui a une adresse et non
> le bâtiment, soyons cohérent de taguer la parcelle (ce qui est

Re: [OSM-talk-fr] schéma des addr

2018-01-05 Per discussione Christian Quest

Marc, tu te trompe sur plusieurs points.

contact:* est documenté et l'était bien avant qu'on en parle ici. Il s'agit
bien d'indiquer pour un POI le moyen de le contacter, pas que via son
adresse. Séparer la définition de l'adresse et celle du POI est assez
logique.

Les deux schémas utilisé pour modéliser les adresses sont largement
utilisables, que ce soit avec les relations ou sans.

On peut tout à fait relancer la discussion, mais comme les éléments de
départs n'ont pas changé, je ne vois pas pourquoi on arriverait à une autre
conclusion.


Il ne faut pas tout mélanger. Là, le départ c'est une anomalie signalée à
juste titre par osmose (si j'ai bien suivi) avec des modifications faites à
moitié.


Les adresses ça semble simple, mais en même temps c'est complexe, ce que
j'ai découvert en bossant ces dernières années sur le sujet. Pour beaucoup
de monde il y a confusion entre adresse et bâtiment (d'où cette tendance à
mettre des adresses sur les polygones de bâtiments) alors que non, ça n'est
pas du 1 vers 1.

J'ai encore dû expliquer à un dev ce matin qui réalisait un écran de saisie
d'adresse sur une borne que non, les codes postaux ne correspondent pas à
une commune... qu'il y a environ 6000 codes postaux et plus de 35000
communes (CQFD).

Peut être devrions nous mieux expliciter tout ça sur le wiki pour bien
faire comprendre la logique des adresses, ce qu'elles sont et ne sont pas,
etc.



Le 5 janvier 2018 à 13:15, marc marc  a écrit :

> Le 04. 01. 18 à 23:53, osm.sanspourr...@spamgourmet.com a écrit :
> > une personne a vire le addr:housenumber parce que trop près de la
> > voirie.
> > http://www.openstreetmap.org/changeset/35942339
>
> le problème est plus large que cela.
> ce qu'on peux lui reprocher :
> ses modifs sont incohérente avec le reste de la rue.
> s'il voulait migrer le nœud addr au profit du bâtiment, il fallait le
> faire au complet = supprimer totalement ce nœud et remplacer le noeud
> par le bâtiment dans la relation assosciatedStreet
> Et idéalement faire toute la rue en une fois pour garder une micro
> cohérence toute symbolique et absurde que cela soie dans ce cas.
>
> L'autre problème, c'est qu'en mettant le nœud quelque part en bordure de
> la parcelle, on confie au hasard le lien entre une adresse et un bâtiment.
> Si on veux tager le fait que c'est la parcelle qui a une adresse et non
> le bâtiment, soyons cohérent de taguer la parcelle (ce qui est hors de
> portée du contributeur moyen).
> Mais un tag de nœud mis positionné sans règle précise, c'est la foire.
> Dans ton lien, il est par exemple impossible de savoir avec certitude
> l'adresse du bâtiment au sud de la rue du Muguet
> https://www.openstreetmap.org/node/2045090782#map=19/48.37680/-4.57899
> peut-être
> 
> est-ce le 27 à moins que le bâtiment de gauche aie 3 adresses
> et que celui du bas n'ai pas encore d'adresse renseignée.
> peut-être même que c'est le 19 Route de Trénen avec une allée privée non
> renseigne. bref, faut prendre une vue satellite pour essayer de deviner
> l'adresse
> La solution de rapprocher le nœud du bâtiment revient implicitement à
> dire qu'on considère qu'il y a un lien entre l'adresse et le bâtiment
> tout en étant incohérent dans le fait de ne pas tager ce lien.
>
> Par conséquent, il ne faut pas s'étonner que des contributeurs finissent
> par ajouter les adresses sur les bâtiments lorsque ceux-ci n'ont qu'une
> adresse ou sur les portes d'entrée.
> Et on a le même problème avec ceux qui placent les poi à l'entrée de la
> parcelle (vu hier le cas hier d'un nœud en bord de route pour désigner
> la présence d'une chambre d'hôte dans un bâtiment des environs)
> aucun lien avec le bâtiment ni son adresse.. donc les gens finissent
> par encoder l'adresse une 3ieme fois.
> certains pensent que ce problème s'évite en utilisant une xieme
> spécificité franco-francaise des contact:addr documenté nulle part et
> donc utilisé par aucune app.
>
> Perso je suis triste de voir toutes ces infos inutilisable dans une
> appli simplement par manque de schéma cohérent.
> J'avais proposé qu'on s'attaque l'an passé à ce dossier difficile
> mais pour le moment, la seule chose sur laquelle on est d'accord,
> c'est le fait qu'on n'est pas d'accord.
> peut-être pourrait-on faire un pas en voyant s'il y a au moins un accord
> pour ouvrir ce chantier, chacun pourrait dire les problèmes pratique
> qu'il rencontre et comment sa façon de tager permet de résoudre ou pas
> ces problèmes.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [Talk-cz] Výzva k hlasování - bazény Fell3 - smazat nebo private

2018-01-05 Per discussione Karel Volný

Dne pátek 5. ledna 2018 12:02:46 CET, jo...@razdva.cz napsal(a):
> Vy vite, co bude za rok?

nevíme, ale předpokládáme ... Honza dal krásný příklad, pojďme smazat všechny 
mosty, protože za rok už tam být nemusí :-)

> Opravdu se chceme dostat do viru bazenu, ktere si
> rodinka po zime vytahne pokazde na trochu jine misto?

já bych jen lehce připomněl, že se nám tady tak trošku ohýbá argumentace 
stranou od původní otázky - to, že se třeba "nechceme dostat do víru bazénů, 
které si rodinka po zimě vytáhne pokaždé na trochu jiné místo", ještě 
neimplikuje nutnost hromadně mazat všechny bazény, o kterých se hlasuje

ono totiž zdaleka ne všechny jsou mobilní ...

> Mam taky spustu tipu na odlozene mobilni bunky,
> jdem do toho?

a můžeme vědět důvod, proč ne, kromě ad hoc pravidla, že to není pevně spojené 
se zemí?

- přinejmenším by bylo vhodné vysvětlit, proč by takové pravidlo mělo platit, 
a za jakých okolností ... jinak tedy, když už argumentujeme ad absurdum jako s 
těmi dětskými stany, bychom mohli říci, že třeba takové hranice také nijak 
spojené se zemí nejsou, v reálu takové čáry prakticky vůbec neexistují, tak 
pojďme smazat z mapy hranice ...

> A mimochodem, mapy mne zivi, proto jsem napsal, co jsem napsal...

ah, argument autoritou, jak osvěžující, to už tu dlouho nebylo :-)

na jednu stranu fajn, že z tebe mluví zkušenost, na druhou stranu potřeby a 
postupy v komerční sféře se dosti často a dosti často zásadně liší od potřeb v 
hobby projektech (že tyto pak mohou být komerčně vy/zne-užity je věc jiná) - 
kdyby byli zakladatelé OSM spokojeni s nabídkou od těch, co se tím živí, 
zjevně by OSM vůbec nevznikla, že

za sebe mám třeba konkrétní příklad k těm věcem nespojeným pevně se zemí, že 
předloni jsme chrápali v jedné takové maringotce, o jejíž umístění se dokonce 
majitelé soudili, takže nepředpokládám, že by si ji v dohlednu chtěli 
přemísťovat ... dostali jsme souřadnice, nicméně pamatuju doby, kdy GPSku 
každej v kapse neměl, a člověk byl občas rád, když takhle v hlubokým lese 
došel k chatě, jako orientačnímu bodu, co měl v mapě, a vůbec by mu nevadilo, 
že ta "chata" je na kolech, pokud se to místo dalo s mapou ztotožnit

K.


signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Výzva k hlasování - bazény Fell3 - smazat nebo private