date:20200103


Le 04/01/2020 à 08:18, Arnaud Champollion a écrit :
Oui, justement dans l'exemple cité, je suis allé voir sur le terrain 
et il y a bien : portail d'un côté, clôture de l'autre, et reste 
d'ancien chemin non entretenu entre les deux.


--> Dans ce cas je serais pour la suppression du chemin.



https://www.openstreetmap.org/way/569947953

Photos 
https://framapic.org/gallery#rlnndlRYOCXY/A0oIv6fCiIp8.jpg,vvZ2L3Pf3CZO/XT6je77NDrVP.jpg



Pour l'autre https://www.openstreetmap.org/way/569944546

je n'ai pas pris de photo mais c'est pire, une forêt de broussailles 
entre les bâtiments.





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

Re: [OSM-talk-fr] Chemins publics / privés / ouverts / fermés


Le 04/01/2020 à 08:00, Christian Quest a écrit :
Ensuite, il n'y a que le terrain qui pourra de toute façon permettre 
de savoir si il y a un panneau de restriction ou pas, une clôture ou 
pas, une chaîne, etc...


Oui, justement dans l'exemple cité, je suis allé voir sur le terrain et 
il y a bien : portail d'un côté, clôture de l'autre, et reste d'ancien 
chemin non entretenu entre les deux.


--> Dans ce cas je serais pour la suppression du chemin.



Pour les autres chemins name=accaparé qu'on a sur Digne et alentours, je 
pense faire en deux temps :



1) modification en masse

--> déplacement en masse de name=accaparé vers description=accaparé
--> ajout en masse de access=private

Comme cela on nettoie les données, sans perdre la main sur ces chemins, 
et on évite que les utilisateurs considèrent les chemins comme d'accès 
public.



2) vérification sur le terrain, et selon le cas :

- suppression du chemin s'il n'existe pas
- ajout de portail ou clôture quand c'est le cas
- suppression de access=private si le chemin est en fait en accès libre



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

Re: [talk-au] Bush Fire Neighbourhood Safer Places

2020-01-03 Diskussionsfäden Graeme Fitzpatrick

On Sat, 4 Jan 2020 at 12:21, adam steer  wrote:

>
> In Vic these are only used as a last resort. Not sure if 'assembly point'
> translates to 'only come here if there are absolutely no other options, and
> this place might not be safe anyway'.
>
>
> It seems that 'neighbourhood safer places' means something different
> across borders. Can anyone in emergency services comment?
>

The Qld version is similar
https://www.ruralfire.qld.gov.au/BushFire_Safety/Neighbourhood-Safer-Places/Pages/default.aspx

"An NSP is a local open space or building where people may gather, as a
last resort, to seek shelter from a bushfire."

  Thanks

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

Re: [OSM-talk-fr] SPAM, Re: Chemins publics / privés / ouverts / fermés


Le 03/01/2020 à 21:47, ades.s...@orange.fr a écrit :

Il y a un chemin ou pas ! sur le terrain, pas sur bing ou l'ortho ign !


Dans l'exemple https://www.openstreetmap.org/#map=19/44.08683/6.22991
je suis allé voir sur le terrain, il n'y a rien.
Si on a l'information et qu'on fouine bien on devine qu'il y a pu y 
avoir quelque chose, mais force est de constater que, dans la réalité 
observable, il n'y a plus de chemin.




je ne suis pas certain que 'private' veuille dire 'privé' en français


D'après le Robert (version papier), si : privé, individuel, 
intime ...
Le Larousse en ligne est un peu plus large, mais même dans l'exemple 
"not for the public" les exemples mélangent allègrement les deux notions 
: https://www.larousse.fr/dictionnaires/anglais-francais/private/604114


Enfin peu importe, tu as raison car, quelque soit sa signification dans 
la langue, pour le fonctionnement d'OSM on s'en tient à celle de 
l'attribut, j'aurais dû en effet commencer par là :


L'attribut access 
=private est 
généralement utilisé en combinaison avec le réseau routier pour indiquer 
que la voie ne doit pas être utilisée par le grand public, ainsi que sur 
d'autres installations. L'accès n'est possible qu'avec une autorisation 
individuelle.




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

Re: [OSM-talk-fr] Chemins publics / privés / ouverts / fermés

2020-01-03 Diskussionsfäden Christian Quest

Le ven. 3 janv. 2020 à 21:50, ades.s...@orange.fr  a
écrit :

> Il y a un chemin ou pas ! sur le terrain, pas sur bing ou l'ortho ign !
> Si il y en a un, soit il est utilisable par tout un chacun, soit il ne
> l'est pas. Dans le premier cas rien à rajouter sauf les éventuelles
> restrictions habituelles :  bourrin, mobylette, piéton etc.
> S'il n'est pas utilisable, à part 'access:no' ou 'private', je ne vois pas
> trop quoi rajouter. En plus je ne suis pas certain que 'private' veuille
> dire 'privé' en français,mais je ne cause pas le langage des grandes dents.
> Que le terrain d'assiette relève d'une propriété publique ou d'une
> propriété privée ne change rien et en plus ce n'est pas visible sur le
> terrain.
> En outre comment on fait si le terrain appartient au domaine privé de
> l'État ou d'une collectivité territoriale ?
>

Il y a des cas évidents où un chemin que l'on voit sur l'ortho est privé,
cas typique de l'accès à un garage sur le terrain d'un pavillon.
Quand on a une belle ortho, on voit même les portails ou les rayures
jaunes/noires des portails automatiques (surtout dans les résidences).
Ces rayures sont une bonne indication sur le fait qu'on ne peut même pas
passer comme piéton.

Le cadastre est une source d'info, mais pas LA source, car certaines
parcelles peuvent être publiques... et sans l'info sur le propriétaire et
ses règles d'usage difficile de faire la part des choses.Ce n'est
effectivement pas parce qu'une parcelle (comme celle d'une école)
appartient à la commune qu'on peu y circuler librement.

Ensuite, il n'y a que le terrain qui pourra de toute façon permettre de
savoir si il y a un panneau de restriction ou pas, une clôture ou pas, une
chaîne, etc...

Je pense que ce sont plus les limites du "armchair mapping" qu'on touche
ici plus qu'autre chose.

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

[Talk-at] ferienpensionen.info

2020-01-03 Diskussionsfäden Günther Zinsberger


Guten Morgen!

Kennt ihr schon https://ferienpensionen.info ?

Sie verwenden anscheinend nach auch OSM in ihrer Karte. (wie schon bei 
der Einstiegsseite)
Bei den Ausschnitten kann ich keinen Hinweis auf OSM erkennen. Klickt 
man auf die Mini-Karte, dann wird die Karte in groß angezeigt und da 
gibt es dann schon einen OSM-Hinweis.


Dasselbe gilt auch bei den einzelnen Pensionen, z.B.:
https://ferienpensionen.info/fr%C3%BChst%C3%BCckspension/gasthaus-jax

Dem Anschein nach hat die Firma ihren Sitz in Bezirk Ried im Innkreis 
bzw. Braunau.
Passt das so für uns oder sollte man die Betreiber noch auf mehr 
Attribution aufmerksam machen?


Grüße,
Günther

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

Re: [Talk-at] Stop area groups

2020-01-03 Diskussionsfäden Stefan Tauner via Talk-at

On Sat, 04 Jan 2020 03:04:36 +0100
Kevin Kofler  wrote:

> Was meint ihr?

Hi,

exakt deiner Meinung. Allerdings wäre es wünschenswert die Motivation
der/des Ändernden zu erfahren.

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

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

[talk-latam] Mejoras en la lista de recursos al guardar cambios en editor iD

2020-01-03 Diskussionsfäden Marco Antonio Frias

Hola,

Estoy mejorando la lista de recursos de «OpenStreetMap América Latina»
que se muestran después de guardar un cambio en el editor iD, ahora se
ve así → https://imgur.com/Ix8YFxV

Añadí los que faltaban: la lista de correo, la wiki, irc, el canal de
matrix, el canal de youtube, github, y el irc, como son varios se
pueden ordenar poniendo arriba los más usados y más abajo los menos
usados...

Así que dejo en este orden:

* telegram - matrix - twitter - irc
* página web osmlatam - wiki
* github - youtube - facebook

¿alguien tiene algún comentario sobre el orden? ¿Se entiende cómo quedaría?

Voy a esperar hasta el martes por la tarde y si no hay comentarios,
mandaré al repo [1] este cambio

Abrazos,

Marco Antonio

[1] https://github.com/osmlab/osm-community-index

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

Re: [talk-au] Fire Station Operators

On Sat, 4 Jan 2020 at 14:14, Sebastian Spiess  wrote:

> Andrew,
> I've done one. Just clarifying regarding the branch.
>
> branch  =   Narrabeen Fire Station
> name   =  Fire and Rescue NSW Station 068 Narrabeen
>

I can't see clearly from Mapillary what the singe looks like, but branch
should be just "Narrabeen", without the "Fire Station" words. Then you
could still have name=Narrabeen Fire Station.

> Is this how you suggested? Before the branch tag was the name.
>
> I've also added
> building =fire_station
>
> https://www.openstreetmap.org/changeset/79179815
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Fire Station Operators

2020-01-03 Diskussionsfäden Sebastian Spiess

Andrew,
I've done one. Just clarifying regarding the branch.

branch  =   Narrabeen Fire Station
name   =  Fire and Rescue NSW Station 068 Narrabeen

Is this how you suggested? Before the branch tag was the name.

I've also added
building =    fire_station

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

On 4/1/20 9:06 am, Andrew Harvey wrote:
> I've updated the Australian Tagging Guidelines with NSW fire station
> operators 
> https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#Fire_Stations.
>
>
> I'm proposing:
>
> for NSW Rural Fire Service stations to use 
> operator=NSW Rural Fire Service
> operator:wikdata=Q7011777
>
> for Fire and Rescue NSW stations to use
> operator=Fire and Rescue NSW
> operator:wikidata=Q5451532
>
> Does that sound okay?
>
> I'm also suggesting to use the "branch=" tag to use the short name of
> the fire station branch, which is usually the suburb name and is
> printed on the fire trucks, since the regular name= tag could contain
> a longer signposted name.
>
> For other states, if this tagging is okay, please help fill in the
> operator and operator:wikidata tags on the wiki page for your states.
>
> I've created a MapRoulette challenge for NSW to fill in these tags
> either as implied from the name, local knowledge or from street lever
> imagery https://maproulette.org/challenge/11820
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au


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

Re: [talk-au] Fire Station Operators

2020-01-03 Diskussionsfäden Sebastian Spiess

Sounds good to me.

On 4/1/20 9:06 am, Andrew Harvey wrote:
> I've updated the Australian Tagging Guidelines with NSW fire station
> operators 
> https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#Fire_Stations.
>
>
> I'm proposing:
>
> for NSW Rural Fire Service stations to use 
> operator=NSW Rural Fire Service
> operator:wikdata=Q7011777
>
> for Fire and Rescue NSW stations to use
> operator=Fire and Rescue NSW
> operator:wikidata=Q5451532
>
> Does that sound okay?
>
> I'm also suggesting to use the "branch=" tag to use the short name of
> the fire station branch, which is usually the suburb name and is
> printed on the fire trucks, since the regular name= tag could contain
> a longer signposted name.
>
> For other states, if this tagging is okay, please help fill in the
> operator and operator:wikidata tags on the wiki page for your states.
>
> I've created a MapRoulette challenge for NSW to fill in these tags
> either as implied from the name, local knowledge or from street lever
> imagery https://maproulette.org/challenge/11820
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au


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

Re: [talk-au] Jervis Bay Territory admin boundary


On 04/01/20 10:57, cleary wrote:

The Jervis Bay Territory/NSW boundary is shown such that Jervis Bay Territory 
overlaps into parts of Shoalhaven Council area and NSW suburbs.  Obviously not 
correct. There seems to be no source provided for the location of the boundary, 
although much of it appears to be attached to the coastline (also source not 
apparent).

There have been a lot of edits to this area and maybe someone more familiar 
with the location wants to repair the map in this area. If not, I propose to 
try to fix it, primarily using the NSW_LPI_BaseMap as the source for the 
boundary.

If no one else wants to do it, I'll work in on it in a few days.



All yours. :)
 



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

Re: [talk-au] Bush Fire Neighbourhood Safer Places

On 04/01/20 13:18, adam steer wrote:

Hi Andrew

In Vic these are only used as a last resort. Not sure if 'assembly
point' translates to 'only come here if there are absolutely no other
options, and this place might not be safe anyway'.

See: https://www.cfa.vic.gov.au/plan-prepare/neighbourhood-safer-places

There are also community fire refuges:
https://www.cfa.vic.gov.au/plan-prepare/community-fire-refuges/

...my reading there is also 'try really hard not to come here, but if
there's nothing else then turn up'.

I think generally they want people well away from the fire area, rather
than close by. Hence the words used.

Could we add a 'place of last resort' tag?

Why? I think the description will tell the story.

Relief centres, eg:
https://www.eastgippsland.vic.gov.au/Council/News_and_Media_Releases/Emergency_Relief_Centres

https://www.wangaratta.vic.gov.au/emergency/relief-and-recovery

...seem to be council operated...
I think those are places to go for food, clothing not for shelter from
the fire. So not the same thing.

It seems that 'neighbourhood safer places' means something different
across borders. Can anyone in emergency services comment?

Thanks,

Adam

On Sat, 4 Jan 2020, 11:30 am Andrew Harvey, > wrote:

I'm not sure what these are called or look like in other states,
but in NSW they look like
https://www.flickr.com/photos/136319147@N08/49324333543/ and they
are operated by the NSW RFS.

emergency=assembly_point seems like the best tag to use per the
wiki
https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dassembly_point "A
designated (safe) place where people can gather or must report to
during an emergency or a fire drill Edit or translate this
description."

Also documented on the wiki is
https://wiki.openstreetmap.org/wiki/Key:assembly_point:fire which
seems fitting.

I'm proposing these be tagged as

emergency=assembly_point
assembly_point:fire=designated
operator=NSW Rural Fire Service
operator:wikidata=Q7011777

could also add description="Bush Fire Neighbourhood Safer Place"
or your state's equivalent.

Any comments? If this sounds good, I'll document this on the
Australian Tagging Guidelines for NSW.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

Re: [talk-au] Bush Fire Neighbourhood Safer Places

2020-01-03 Diskussionsfäden adam steer

Hi Andrew

In Vic these are only used as a last resort. Not sure if 'assembly point'
translates to 'only come here if there are absolutely no other options, and
this place might not be safe anyway'.

See: https://www.cfa.vic.gov.au/plan-prepare/neighbourhood-safer-places

There are also community fire refuges:
https://www.cfa.vic.gov.au/plan-prepare/community-fire-refuges/

...my reading there is also 'try really hard not to come here, but if
there's nothing else then turn up'.

Could we add a 'place of last resort' tag?

Relief centres, eg:
https://www.eastgippsland.vic.gov.au/Council/News_and_Media_Releases/Emergency_Relief_Centres
https://www.wangaratta.vic.gov.au/emergency/relief-and-recovery

...seem to be council operated...

It seems that 'neighbourhood safer places' means something different across
borders. Can anyone in emergency services comment?

Thanks,

Adam






On Sat, 4 Jan 2020, 11:30 am Andrew Harvey, 
wrote:

> I'm not sure what these are called or look like in other states, but in
> NSW they look like
> https://www.flickr.com/photos/136319147@N08/49324333543/ and they are
> operated by the NSW RFS.
>
> emergency=assembly_point seems like the best tag to use per the wiki
> https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dassembly_point "A
> designated (safe) place where people can gather or must report to during an
> emergency or a fire drill Edit or translate this description."
>
> Also documented on the wiki is
> https://wiki.openstreetmap.org/wiki/Key:assembly_point:fire which seems
> fitting.
>
> I'm proposing these be tagged as
>
> emergency=assembly_point
> assembly_point:fire=designated
> operator=NSW Rural Fire Service
> operator:wikidata=Q7011777
>
> could also add description="Bush Fire Neighbourhood Safer Place" or your
> state's equivalent.
>
> Any comments? If this sounds good, I'll document this on the Australian
> Tagging Guidelines for NSW.
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[Talk-at] Stop area groups

2020-01-03 Diskussionsfäden Kevin Kofler

Hallo,

(There is an English version below the German.)

Mir ist aufgefallen, daß in letzter Zeit in Wien immer mehr "stop_area"s in 
mehrere Teile aufgespalten und in "stop_area_group"s zusammengefaßt wurden. 
Z.B. gibt es jetzt nicht mehr eine stop_area mit name="Matzleinsdorfer 
Platz", sondern jeweils:
* eine mit name="Matzleinsdorfer Platz (S-Bahn)"
* eine mit name="Matzleinsdorfer Platz (tram)"
* eine mit name="Matzleinsdorfer Platz (bus)"
* sowie eine stop_area_group mit name="Matzleinsdorfer Platz"

Diese Suffixe ("(S-Bahn)" usw.) existieren offiziell nicht. Ist es wirklich 
sinnvoll, die Haltestellen so aufzuteilen? Oder wäre es nicht besser, eine 
einzige stop_area mit dem offiziellen Namen "Matzleinsdorfer Platz" zu 
haben? Es ist ja alles eigentlich eine Haltestelle.

Für mich ergibt stop_area_group nur dann Sinn, wenn die Teilhaltestellen 
tatsächlich unterschiedliche Namen haben (z.B. "Hauptbahnhof" vs. 
"Südtiroler Platz – Hauptbahnhof" vs. "Hauptbahnhof Ost" vs. "Hauptbahnhof 
Süd", bzw. "Volkstheater" vs. "Ring, Volkstheater").

Die künstlichen Suffixes sind oft nicht einmal konsistent (z.B. "(U-Bahn 1)" 
vs. "U1"), bzw. enthalten englische Beschreibungen wie "Railway Station" 
oder "(north bus)".

Ich würde gerne diese "stop_area"s wieder vereinen (1 Name = 1 stop_area, 
keine künstlichen Suffixes). Was meint ihr?

Since I am also going to point international committers to this thread, here 
is an English version:

I have noticed that, recently, in Vienna, more and more "stop_area"s have 
been split into multiple parts and grouped together in "stop_area_group"s. 
E.g., there is no longer one single stop_area with name="Matzleinsdorfer 
Platz", but respectively:
* one with name="Matzleinsdorfer Platz (S-Bahn)"
* one with name="Matzleinsdorfer Platz (tram)"
* one with name="Matzleinsdorfer Platz (bus)"
* plus one stop_area_group with name="Matzleinsdorfer Platz"

Those suffixes ("(S-Bahn)" etc.) do not exist officially. Does it really 
make sense to split the stops that way? Or would it not make more sense to 
have one single stop_area with the official name "Matzleinsdorfer Platz"? In 
fact, it is actually just one stop.

To me, stop_area_group makes sense only when the stop parts actually have 
different names (e.g., "Hauptbahnhof" vs. "Südtiroler Platz – Hauptbahnhof" 
vs. "Hauptbahnhof Ost" vs. "Hauptbahnhof Süd", resp. "Volkstheater" vs. 
"Ring, Volkstheater").

The artificial suffixes are often not even consistent (e.g. "(U-Bahn 1)" vs. 
"U1"), or they contain English descriptions such as "Railway Station" or 
"(north bus)".

I would like to reunite those "stop_area"s (1 name = 1 stop_area, no 
artificial suffixes). What do you think?

Kevin Kofler


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

Re: [OSM-talk-fr] SPAM, Re: SPAM, Re: Chemins publics / privés / ouverts / fermés

2020-01-03 Diskussionsfäden Philippe Verdy

à priori oui, l'absence de numéro indiquant que le terrain n'a pas été cédé
sur un acte administratrif ou natarié, pour lequel les numéros de parcelles
sont nécessaires. S'il n'a pas été cédé, il est public. En général on en
trouve sur les lits de rivières, et le domaine maritime, ainsi que les
routes et rues les plus anciennes (datant d'avant la création du cadastre
Napoléon).

Les parcelles ont été ensuite découpées et numérotées au fur et à mesure
des cessions ou de la reconnaissance de propriété, par une occupation
privée suffisamment longue pour qu'elle devienne parmanente et soit
opposable : la durée d'occupation est maintenant dans la loi; au delà
l'état qui voudrait reprendre une parcelle devra la racheter ou
l'exproprier avec indemnisation au prix du marché des terrains autour (et
même si la perte d'usage du terrain résulte d'une catastrophe naturelle ou
industrielle, ou d'un arrêté de danger/péril imminent et non d'une
expropriation négociée; mais l'état n'indemnise pas tout, les occupants
doivent aussi avoir leurs assurances pour compenser les dommages matériels
ou d'exploitation).

Des cas sont cependant prévus par la loi où l'Etat peut se saisir de plein
droit certains terrains occupés (cas du domaine maritime, même occupé
depuis très longtemps), mais il donne alors un préavis avant l'expulsion et
l'occupant n'est pas toujours obligé de restaurer le terrain à l'état
naturel ou de prendre ne charge les frais de démolition (il peut en
revanche avoir à prendre en charge tout ou partie des frais de dépollution
dont il pourrait avoir été responsable).

Je ne vois pas comment une parcelle non numérotée peut être privée (sauf
gros bogue du cadastre ayant omis d'inscrire un acte de propriété valide ou
une décision de justice ayant reconnu une propriété). C'est justement pour
réglementer les propriétés et régler les litiges (aussi pour percevoir les
taxes locales et les justifier) que le cadastre existe; pourtant les taxes
locales ne sont pas égales pour tous car ça varie énormément d'une
collectivité à l'autre et la "valeur locative" n'a jamais été réévaluée en
fonction des prix de cession du marché (sur lesquels l'Etat devrait
acquérir les parcelles privées, ou les exproprier après enquête d'utilité
publique ou un arrêté de péril, une fois passé les délais légaux de recours
judiciaire).



Le ven. 3 janv. 2020 à 20:39, Arnaud Champollion <
arnaud.champoll...@linux-alpes.org> a écrit :

> Le 03/01/2020 à 20:12, Philippe Verdy a écrit :
> > La présence d'un numéro n'indique donc pas si la parcelle est publique
> > ou privée.
>
>
> OK, mais du coup, l'absence de numéro permet-il de dire que la parcelle
> est publique ?
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-bo] Retos de MapRoulette en Bolivia

2020-01-03 Diskussionsfäden Andrew Wiseman via Talk-bo

Saludos,

Actualicé los retos con datos nuevos para Bolivia. Hay una pagina aquí con 
todos los retos incluyendo caminos cruzando, carreteras flotantes, vías 
superpuestas, problemas de enrutamiento y otros. También hay un reto nuevo 
sobre inconsistencias de ortografía del nombre del camino -- cuando vías 
conectadas tienen nombres similares.

https://maproulette.org/browse/projects/38986 


Muchas gracias,

Andrew 

Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 


> On Oct 24, 2019, at 2:34 PM, Andrew Wiseman via Talk-bo 
>  wrote:
> 
> Hola,
> 
> Recientemente actualizamos los desafíos de MapRoulette con datos nuevos y 
> agregamos algunos más desafíos. Aquí hay nuevos enlaces a ellos. Por favor 
> hazme saber si tienes alguna pregunta.
> 
> Bolivia calles y vías con ángulos agudos: 
> https://maproulette.org/challenge/9489 
> 
> Bolivia comprobación de conectividad vial: 
> https://maproulette.org/challenge/9494 
> 
> Bolivia caminos y vías cruzados: https://maproulette.org/challenge/9497 
> 
> Bolivia caminos y vías flotantes y desconectadas: 
> https://maproulette.org/challenge/9487 
> 
> Bolivia restricciones de giro no válidas: 
> https://maproulette.org/challenge/9491 
> 
> Bolivia rotondas malformadas: https://maproulette.org/challenge/9492 
> 
> Bolivia líneas superpuestas: https://maproulette.org/challenge/9496 
> 
> Bolivia enlaces de carreteras: https://maproulette.org/challenge/9495 
> 
> Bolivia enrutamiento imposible: https://maproulette.org/challenge/9490 
> 
> Saludos, 
> 
> Andrew
> 
> 
> 
> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
> 
> 
>> On Feb 18, 2019, at 4:47 PM, Andrew Wiseman via Talk-bo 
>> mailto:talk-bo@openstreetmap.org>> wrote:
>> 
>> Hola OSM Bolivia,
>> 
>> Esto es Andrew del equipo de mapas de Apple. Llevamos algún tiempo 
>> trabajando en los datos de Bolivia 
>> (https://github.com/osmlab/appledata/issues/90 
>> ) y recientemente usado 
>> nuestro herramienta Atlas para análisis de datos 
>> (https://github.com/osmlab/atlas ) para 
>> buscar algunos tipos de posibles problemas, como carreteras con ángulos 
>> agudos, intersecciones de edificios y carreteras, lineas (frecuentemente 
>> vías) superpuestas, y lugares donde la clasificación de “highway_link” no 
>> coincide con la clasificación más alta de las carreteras. Pongo los 
>> resultados de los retos en MapRoulette (maproulette.org 
>> ), un herramienta que te permite pasar los 
>> problemas uno por uno y corregirlos o marcar que no son un problema. Quería 
>> hacerles saber que estaban disponibles en caso de que alguien quisiera 
>> intentar arreglarlos. Yo también arreglaré algunos.
>> 
>> En MapRoulette escoges un problema random o haz clic en un problema 
>> especifico. Si desea ver tareas en un lugar determinado, como en un lugar 
>> con el que está familiarizado, puede hacer clic en "más opciones" y luego en 
>> “load tasks by proximity” (cargar tareas por proximidad.)
>> 
>> Por favor, hágamelo saber si tiene alguna pregunta o comentario.
>> 
>> Los retos son:
>> 
>> Carreteras y vías de ángulo agudo: 
>> https://maproulette.org/mr3/challenge/3677 
>> 
>> Intersecciones de edificios y carreteras: 
>> https://maproulette.org/mr3/challenge/3674 
>> 
>> Carreteras de enlaces: https://maproulette.org/mr3/challenge/3675 
>> 
>> Superpuestas de lineas: https://maproulette.org/mr3/challenge/3676 
>> 
>>  
>> Muchas gracias,
>> 
>> Andrew
>> 
>> 
>> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
>> 
>> ___
>> Talk-bo mailing list
>> Talk-bo@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-bo
> 
> ___
> Talk-bo mailing list
> Talk-bo@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-bo

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

[talk-au] Bush Fire Neighbourhood Safer Places

I'm not sure what these are called or look like in other states, but in NSW
they look like https://www.flickr.com/photos/136319147@N08/49324333543/ and
they are operated by the NSW RFS.

emergency=assembly_point seems like the best tag to use per the wiki
https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dassembly_point "A
designated (safe) place where people can gather or must report to during an
emergency or a fire drill Edit or translate this description."

Also documented on the wiki is
https://wiki.openstreetmap.org/wiki/Key:assembly_point:fire which seems
fitting.

I'm proposing these be tagged as

emergency=assembly_point
assembly_point:fire=designated
operator=NSW Rural Fire Service
operator:wikidata=Q7011777

could also add description="Bush Fire Neighbourhood Safer Place" or your
state's equivalent.

Any comments? If this sounds good, I'll document this on the Australian
Tagging Guidelines for NSW.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[talk-au] Jervis Bay Territory admin boundary

2020-01-03 Diskussionsfäden cleary

The Jervis Bay Territory/NSW boundary is shown such that Jervis Bay Territory 
overlaps into parts of Shoalhaven Council area and NSW suburbs.  Obviously not 
correct. There seems to be no source provided for the location of the boundary, 
although much of it appears to be attached to the coastline (also source not 
apparent).

There have been a lot of edits to this area and maybe someone more familiar 
with the location wants to repair the map in this area. If not, I propose to 
try to fix it, primarily using the NSW_LPI_BaseMap as the source for the 
boundary.

If no one else wants to do it, I'll work in on it in a few days.

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

[OSM-talk-fr] Requête OverpassTurbo

2020-01-03 Diskussionsfäden Donat ROBAUX

Bonjour,

Est-ce que quelqu'un sait:
- si on peut moduler la taille de la police d'écriture des étiquettes de
/text: name/ par exemple. Quand je requête, ca prend une place folle et ce
n'est plus lisible. 
https://wiki.openstreetmap.org/wiki/FR:Overpass_turbo/MapCSS#Marqueurs_avec_texte

  
- comment requêter sur plusieurs zones géographiques en même temps, ex: 2
départements?

Je précise que c'est sur OverpassTurbo, je ne sais pas utiliser Overpass
API.

Merci d'avance.
Donat



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [talk-au] Fire Station Operators

2020-01-03 Diskussionsfäden cleary


Yes. This seems right.




On Fri, 3 Jan 2020, at 10:06 PM, Andrew Harvey wrote:
> I've updated the Australian Tagging Guidelines with NSW fire station 
> operators 
> https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#Fire_Stations.
> 
> I'm proposing:
> 
> for NSW Rural Fire Service stations to use 
> operator=NSW Rural Fire Service
> operator:wikdata=Q7011777
> 
> for Fire and Rescue NSW stations to use
> operator=Fire and Rescue NSW
> operator:wikidata=Q5451532
> 
> Does that sound okay?
> 
> I'm also suggesting to use the "branch=" tag to use the short name of 
> the fire station branch, which is usually the suburb name and is 
> printed on the fire trucks, since the regular name= tag could contain a 
> longer signposted name.
> 
> For other states, if this tagging is okay, please help fill in the 
> operator and operator:wikidata tags on the wiki page for your states.
> 
> I've created a MapRoulette challenge for NSW to fill in these tags 
> either as implied from the name, local knowledge or from street lever 
> imagery https://maproulette.org/challenge/11820
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>

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

Re: [talk-au] parking and bike lane

On Tue, 31 Dec 2019 at 19:42, Warin <61sundow...@gmail.com> wrote:

> For safety I think you will find all bicycle lanes end before any
> roundabout and restart after the roundabout.. helps stop cars exiting over
> cyclists, well it is supposed to...
>

The exception to that could be 3 road junction roundabouts in a T shape
where a bike lane could continue across the straight road.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Addresses/street numbers

The GNAF license is pretty open, just not open enough for importing to
OpenStreetMap. I'd still recommend any services trying to do geocoding to
also use GNAF as fallback source if not found in OSM.

On Fri, 3 Jan 2020 at 11:04, Michael Shafer  wrote:

> Hey everyone,
>
> I noticed that street number information is quite sparse around where I
> live in Sydney, then saw it’s because the GNAF license is incompatible with
> OSM (as tracked by @aharvey here:
> https://wiki.openstreetmap.org/wiki/Australian_data_catalogue).
>
> This is pretty unfortunate as it means address search and routing tools
> can only point you to the street, but not the individual property. (Noticed
> when trying to geocode my own address!)
>
> Does anyone know of other techniques for getting address information at
> scale? e.g. does Mapillary try to detect street numbers from street-level
> imagery?
>
> Interestingly Mapbox does have street numbers where I live, I wonder where
> they are getting that information.
>
> Thanks,
> Michael
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] presenting #NorthernBeachesSolar pet project

Nice work, would love to see more roof top solar panels mapped.

The Tasking Manager https://wiki.openstreetmap.org/wiki/Tasking_Manager might
suit this better than MapRoulette, since Tasking Manager breaks an area up
into tiles and you go in, choose a tile, complete it, then upload. It helps
track progress, avoid conflicts and ensures a whole area is done without
gaps in coverage.

MapRoulette works differently, it's based on identifying features already
which need some work.

> start_date=* - set to the date of the LPI NSW Imagery - or should this be
rather source:date=*??

start_date is when the feature started, so when the solar panel was
installed, you can just do  if you only know the year or -MM if you
only know the month, but if you don't know you can omit it. source:date is
better for the imagery date.

On Thu, 2 Jan 2020 at 08:50, Sebastian S.  wrote:

> So far I have not worked out a good grid method.
> I go by suburb in my area and keep the file local until I've completed the
> suburb. Only then I upload.
> While offline I use a temporary area tagged as wood. I expand this box
> over the area I've worked through. This is just because I don't know any
> better solution. 
>
> If you want to see a map showing the modules you can use open
> infrastructure map, link is at the bottom of the wiki.
>
> I thought about making this a mapping challenge on
> https://wiki.openstreetmap.org/wiki/MapRoulette but so far I've not
> looked into it. I've got no experience with this but am happy to receive
> guidance.
>
>
> On 2 January 2020 7:11:07 am AEDT, Dion Moult  wrote:
>>
>> On Wed, Jan 01, 2020 at 11:29:13PM +1100, Sebastian Spiess wrote:
>>
>>> I'd like to present my latest pet project:
>>> https://wiki.openstreetmap.org/wiki/User:ConsEbt/NorthernBeachesSolar
>>> I wanted to share this and collect some feedback or comments.
>>>
>>
>> I love it! I might do a bit of solar mapping too! How easy is it to set a 
>> grid
>> to know which areas have been mapped?
>>
>> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Did the Earth just move for you?

On Fri, 3 Jan 2020 at 21:17, Warin <61sundow...@gmail.com> wrote:

> The change is ~ 1.8 meters so most people are unlikely to know as
> general GPS accuracy is greater than the 1.8 metres.
>

Agreed.

We do have aerial imagery in NSW and ACT which are reportedly accurate
enough that the datum matters

The OSM platform isn't currently setup to support a dynamic datum, really
only once consumer GNSS get's more accurate will it start to matter. See
also https://www.openstreetmap.org/user/StephaneP/diary/390290
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-ca] Importing buildings in Canada

2020-01-03 Diskussionsfäden Tim Elrick

Thank you, Daniel, for advancing on the import! I agree with most of 
what you said below (I will reply to some details on the wiki page).


I also agree to separate the different sources as I have great 
reservations about using Microsoft's building footprints for an import 
into OSM (the outlines are simply not good enough in their topology).


Let's get this going,
Tim




On 2020-01-03 15:40, Daniel @jfd553 wrote:
Bonjour groupe, mes excuses pour ce très long courriel !-)

I have reviewed everything that has been written on the ODB import (aka
Canada Building Import) in Talk-ca and the wiki. I proposed changes to
some wiki pages (via talk tabs) to ease the discussions about this
import and the following. Now, in order to restart the import, here are
some thoughts and a proposal on how to proceed to complete the task.

*1. Issues with the ODB Data Import*

Many concerns were raised about the import. One major concern was to
obtain local communities’ buy-in in the Canadian context. Another
concern was to improve the quality of the data prior the import. The
following paragraphs intend to clear most of these concerns.

*1.1. Which data import project?*

According to the import guidelines (steps 3 & 4), a data import
explicitly refers to a single data source (ODB in our case). Discussions
about the availability and quality of Microsoft or ESRI data, while
interesting, are not relevant as they should be dealt with as other
import projects.

*1.2. What has been imported so far?*

According to what I found [1], the ODB import is completed for 21
municipalities. These imports seem to have kept OSM content’s history,
at least for the samples checked, but many problems were found. In some
case, the imports brought swimming pools in OSM because they were
included in the dataset (e.g. Moncton). In other cases, importing
buildings with accurate locations (XY) over content mapped from less
accurate imagery resulted in buildings that now overlap the street
network (e.g. Squamish). It means that all these 21 imports need to be
carefully re-examined and corrected as required.

For 12 other municipalities, the import is partial, either suspended as
requested, or because previous imports had already provided most of the
buildings (often from the same municipal provider). That said the import
will definitely improve OSM accuracy and completeness if done properly.

*2. How should ODB Data be imported?*

I will copy the following paragraphs in the “Canada Building Import”
wiki page [3] for a detailed discussion…

Since the data (ODB, OSM and imagery) differ from one municipality to
another, there can be no imports at the national or provincial level. We
have to work on a municipal basis and make sure to identify all the
problems and the corrective measures to apply when dealing with issues
like those I identified [1].

*2.1 Importing Locally*

According to the import guidelines (step 2), we must not import the data
without local buy-in. However, and contrarily to some European country,
there is usually no such thing as a local OSM community in each
municipality. However, we may find a few local mappers from time to
time. Working on a municipal basis should allow identifying these local
mappers before doing the import. I often use this tool [2] to identify
and contact local mappers. Once identified, I suggest that…

- We contact them to explain our intents by referring to appropriate
wiki pages.

- We wait a week or two to let them respond nothing, that they have
concerns, or wish to help.

- Without negative answers we could proceed to the import.

I first suggest that when a contributor wishes to import ODB for a given
municipality, he first identifies himself as responsible for the import
(we need to create an entry for each municipality somewhere in the
wiki). He can then contact local mappers, as explain above, and go ahead
with the import once everything settled. For those who already made the
import, I suggest that they review their work since many issues were
detected with some of these imports.

Since there are only a few local OSM communities in Canada, and because
Canada is large, I suggest not limiting the import of a given
municipality to the people of the concerned province or region.

*2.2 Pre-processing*

Once local mappers have agreed, some pre-processing can be done if
required.

A few months ago, I developed a tool that could be used to process the
data [4]. Concerns were raised because the application was developed
using proprietary software. So I documented the whole process and
algorithms in order to see courageous coders converting it in open
source software. In the meantime, and as long as I have access to an FME
licence, I could process the data, when necessary, prior to make it
available through the task manager.

Proposed pre-processing [4] includes:

- Reading of original ODB data,

- Removal of near collinear nodes (simplification),

- Orthogonalization of buildings (for corners having near

Re: [OSM-talk] JOSM: Display time of a gpx track

2020-01-03 Diskussionsfäden Tom Pfeifer


https://wiki.openstreetmap.org/wiki/JOSM/Plugins/InfoMode
is your friend:

  *  Displaying GPX trackpoint info - timestamp, velocity, height, track name 
and length.
  *  Hiding individual tracks and tracks older than selected.

tom

On 03.01.2020 19:36, tshrub wrote:

hi,
if I load gpx data as layer, how can I see the points & time from those?
With an extension I can see heights, that's fine.
Is there anything similar for the time - maybe popup-like when moving the mouse 
over it?
regards


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

[talk-au] Fire Station Operators

I've updated the Australian Tagging Guidelines with NSW fire station
operators
https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#Fire_Stations
.

I'm proposing:

for NSW Rural Fire Service stations to use
operator=NSW Rural Fire Service
operator:wikdata=Q7011777

for Fire and Rescue NSW stations to use
operator=Fire and Rescue NSW
operator:wikidata=Q5451532

Does that sound okay?

I'm also suggesting to use the "branch=" tag to use the short name of the
fire station branch, which is usually the suburb name and is printed on the
fire trucks, since the regular name= tag could contain a longer signposted
name.

For other states, if this tagging is okay, please help fill in the operator
and operator:wikidata tags on the wiki page for your states.

I've created a MapRoulette challenge for NSW to fill in these tags either
as implied from the name, local knowledge or from street lever imagery
https://maproulette.org/challenge/11820
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Did the Earth just move for you? RE WGS84

2020-01-03 Diskussionsfäden Georges Dutreix via Talk-fr


On 03/01/20 21:40, Dion Moult wrote:

My impression was that the 1.8m jump was to do with the GDA standard (and
therefore the MGA standards too).


It is not a jump, physically Australia is slowly moving NE all the time (in 
relation to the 'rest of the world').
Some time in the future we may bump into Indonesia, PNG + New Zealand, unless 
something changes.



These seem like Australian specific coordinate
systems that are being adjusted. I assumed that OSM stored its data in WGS84,
which to my understanding is separate to a new definition of a GDA standard.

However, my understanding on this topic is very poor, so if others can help
explain the implications this has on OSM, if any, I'd really appreciate it :)


WGS84 is world wide, so Australia is moving in relation to WGS84.

Typical GPS error is >> 1.8 metres so the change is not that significant.

Other places in the world are also moving, but us Ozies are the fastest movers.


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

Re: [Talk-us] Jefferson Notch Road and latest "GPS made me do it" in the news

2020-01-03 Diskussionsfäden Bill Ricker

On Fri, Jan 3, 2020 at 2:21 PM Kevin Broderick 
wrote:

> However, that assumes that you can trust the news to be accurate,
>

Always a questionable assumption -- whenever you know the facts behind a
story, you see what they get wrong.

> and the distinction between "closed in winter" and "not maintained for
> winter travel" is not one I expect the news media to get right. The article
> I saw quoted the driver has having seen a "Not maintained for winter
> travel" sign and continuing because he didn't think that implied a closure
> (which is true, even if it may be a poor choice in a minivan).
>

At this point i wouldn't trust the driver's statements even without a
reporter re-writing them.

I would want to see, or see a photo of, the sign before I personally
touched that road and it's gate nodes.

(Is there a NH list where that discussion should move? My question here is
what tags are appropriate for the several possibilities.)

Given that it is a snowmachine trail, "closed" seems more likely
>

That the news reports the driver was cited (given a ticket/summons) for
something like driving a car on road closed to cars does indicate that the
cops consider it closed, whatever the sign actually says.

> (and it would be exceedingly impolite to put wheel ruts into a groomed
> trail, even if legal),
>

Yes indeed.
(Emergency services excepted.)

> but it's been long enough since I traveled it that I can't recall the
> signage.
>

I don't recall if we ever used that scenic shortcut - we certainly did
various 2/302/Kancamagus loops, mid last century, through all the other,
major notches, both summer and leaf-peeper.
Now I want to drive this notch sometime before peak-leaf-peeper :-D.

(I am painfully aware how rusty my snowmobile skills are and would not
attempt it in winter unless in a group tour with a paid professional guide
and roustabouts to get me unstuck ! :-D  Knowing your own limits is key in
the back-country.)

> My fuzzy recollection is a gate on the Base Station end.
>

There was already an old Note requesting clarification of the
status/signage of the Gate there in OSM, so you are likely correct that it
is (or was!) there.

I can't find a definitive answer on the NH DOT site, and the WMNF MVUM
> shows it to be a non-forest road through the forest.
>

Thanks for searching !

// Bill, exiled in Boston, Flatland, USA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-talk-fr] Fwd: Re: Casemate


C'est moi qui ai mal répondu, désolé... Je transfère à la liste.


 Message transféré 
Sujet : Re: [OSM-talk-fr] Casemate
Date :  Fri, 3 Jan 2020 19:22:10 +0100
De :Muselaar 
Pour :  Georges Dutreix 



Bonsoir,

Je reprends en haut, pour ne pas noyer plus les citations. En effet, ce 
n'est pas moi qui ai écrit la phrase citée, mais je l'avais reprise pour 
y répondre. C'est yves.prat...@gmail.com qui l'avait écrite.


Du coup, ce mail était destiné à moi, à Yves, ou à la liste ? Car 
apparemment, j'en suis le seul destinataire…


Quoi qu'il en soit, je peux répondre tout de suite à l'excellente idée 
de building:part=* que ça serait assez difficile à utiliser, puisque 
dans ce type de bâtiments, absolument rien n'est visible sur une 
orthophoto, à part des aérations.


Il y a des bâtiments plus célèbres qui sont dans le même genre, et je 
constate que rien n'a été signalé dans OSM sur le fait qu'ils étaient 
invisibles sur une orthophoto, mis à part, encore une fois, des 
aérations et des puits de lumière. Il s'agit d'une réalisation récente 
de Renzo Piano, c'est quand même une référence :


https://www.openstreetmap.org/query?lat=47.70438=6.61914

https://www.openstreetmap.org/way/303538138

Après une bataille juridique avec les héritiers de Le Corbusier, Piano a 
été contraint d'opter pour cette solution, afin que, depuis la célèbre 
chapelle, on ne voit absolument rien du nouveau monastère.


PS : je ne me permets de poster cette réponse sur la liste, puisque le 
message m'était spécialement destiné, mais je donne mon accord pour la 
publication.


Muselaar


Le 03/01/2020 à 17:19, Georges Dutreix a écrit :


Bonjour,

Le 03/01/2020 à 10:52, Muselaar a écrit :
Mais pour moi, ce ne sont pas 2 polygones fermés, mais un seul avec 
avec des segments « underground ».

Sur le rendu, ils seraient représentés en pointillés.



J'aurais tendance à imaginer un usage de building:part=* comme pour 
les rendus 3D des toitures ou d'un bâtiment avec des hauteurs différentes.


https://wiki.openstreetmap.org/wiki/Simple_3D_buildings


Georges

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

Re: [Talk-us] Jefferson Notch Road and latest "GPS made me do it" in the news

2020-01-03 Diskussionsfäden Nathan Grasso

Since OSM is used around the world, shouldn't intellectual property laws in
other countries be considered?

Nathan Grasso
https://osm.org/user/Hexocyte

On Fri, Jan 3, 2020 at 2:12 PM Mark Wagner  wrote:

> In the United States, facts can't be copyrighted, only specific ways of
> expressing them.  If a news article says "the road is closed in the
> winter from Wherezit Junction to Anytown", you can freely extract the
> fact of the closure, look for the OSM ways corresponding to the
> description, and apply a "closed in the winter" tag.
>
> (If the news article instead has a map of the closure, the copyright
> situation becomes more questionable, because now you're copying not
> just the facts of the closure, but possibly the way they're expressed
> as well.)
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-ca] Importing buildings in Canada

2020-01-03 Diskussionsfäden john whelan

Sounds sane to me.

Thanks John

On Fri, 3 Jan 2020 at 16:05, Daniel @jfd553  wrote:

> Hi John,
>
> To comply with the import directive, I would like the discussion to
> continue on the current ODB import only. Could we talk about other sources
> of potential imports at another time? -)
>
>
>
> Thanks
>
> Daniel
>
> *From:* john whelan [mailto:jwhelan0...@gmail.com]
> *Sent:* Friday, January 03, 2020 15:57
> *To:* Daniel @jfd553
> *Cc:* talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] Importing buildings in Canada
>
>
>
> Sounds sane to me.
>
>
>
> Are we thinking of setting up a second import to handle Microsoft building
> outlines on a similar basis? Or extending this one?  I only ask since if we
> are doing it municipality by municipality it might be an idea to identify
> those municipalities that do not have suitable open data through stats
> canada.  I can see us with a list of municipalities and a data source and I
> think it probably should be in one place.
>
>
>
> Cheerio John
>
>
>
> On Fri, 3 Jan 2020 at 15:42, Daniel @jfd553  wrote:
>
> Bonjour groupe, mes excuses pour ce très long courriel !-)
>
> I have reviewed everything that has been written on the ODB import (aka
> Canada Building Import) in Talk-ca and the wiki. I proposed changes to some
> wiki pages (via talk tabs) to ease the discussions about this import and
> the following. Now, in order to restart the import, here are some thoughts
> and a proposal on how to proceed to complete the task.
>
>
>
> *1. Issues with the ODB Data Import*
>
> Many concerns were raised about the import. One major concern was to
> obtain local communities’ buy-in in the Canadian context. Another concern
> was to improve the quality of the data prior the import. The following
> paragraphs intend to clear most of these concerns.
>
> *1.1. Which data import project?*
>
> According to the import guidelines (steps 3 & 4), a data import explicitly
> refers to a single data source (ODB in our case). Discussions about the
> availability and quality of Microsoft or ESRI data, while interesting, are
> not relevant as they should be dealt with as other import projects.
>
> *1.2. What has been imported so far?*
>
> According to what I found [1], the ODB import is completed for 21
> municipalities. These imports seem to have kept OSM content’s history, at
> least for the samples checked, but many problems were found. In some case,
> the imports brought swimming pools in OSM because they were included in the
> dataset (e.g. Moncton). In other cases, importing buildings with accurate
> locations (XY) over content mapped from less accurate imagery resulted in
> buildings that now overlap the street network (e.g. Squamish). It means
> that all these 21 imports need to be carefully re-examined and corrected as
> required.
>
> For 12 other municipalities, the import is partial, either suspended as
> requested, or because previous imports had already provided most of the
> buildings (often from the same municipal provider). That said the import
> will definitely improve OSM accuracy and completeness if done properly.
>
> *2. How should ODB Data be imported?*
>
> I will copy the following paragraphs in the “Canada Building Import” wiki
> page [3] for a detailed discussion…
>
> Since the data (ODB, OSM and imagery) differ from one municipality to
> another, there can be no imports at the national or provincial level. We
> have to work on a municipal basis and make sure to identify all the
> problems and the corrective measures to apply when dealing with issues like
> those I identified [1].
>
> *2.1 Importing Locally*
>
> According to the import guidelines (step 2), we must not import the data
> without local buy-in. However, and contrarily to some European country,
> there is usually no such thing as a local OSM community in each
> municipality. However, we may find a few local mappers from time to time.
> Working on a municipal basis should allow identifying these local mappers
> before doing the import. I often use this tool [2] to identify and contact
> local mappers. Once identified, I suggest that…
>
> - We contact them to explain our intents by referring to appropriate wiki
> pages.
>
> - We wait a week or two to let them respond nothing, that they have
> concerns, or wish to help.
>
> - Without negative answers we could proceed to the import.
>
> I first suggest that when a contributor wishes to import ODB for a given
> municipality, he first identifies himself as responsible for the import (we
> need to create an entry for each municipality somewhere in the wiki). He
> can then contact local mappers, as explain above, and go ahead with the
> import once everything settled. For those who already made the import, I
> suggest that they review their work since many issues were detected with
> some of these imports.
>
> Since there are only a few local OSM communities in Canada, and because
> Canada is large, I suggest not limiting the import of a given municipality
>

Re: [Talk-ca] Importing buildings in Canada

2020-01-03 Diskussionsfäden Daniel @jfd553

That is why I proposed changes in some wiki page (talk), to deal with many 
imports, without mixing discussions :-)

Daniel

From: Daniel @jfd553 [mailto:jfd...@hotmail.com]
Sent: Friday, January 03, 2020 16:06
To: john whelan; Daniel @jfd553
Cc: talk-ca@openstreetmap.org
Subject: RE: [Talk-ca] Importing buildings in Canada

Hi John,
To comply with the import directive, I would like the discussion to continue on 
the current ODB import only. Could we talk about other sources of potential 
imports at another time? -)

Thanks
Daniel
From: john whelan [mailto:jwhelan0...@gmail.com]
Sent: Friday, January 03, 2020 15:57
To: Daniel @jfd553
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Importing buildings in Canada

Sounds sane to me.

Are we thinking of setting up a second import to handle Microsoft building 
outlines on a similar basis? Or extending this one?  I only ask since if we are 
doing it municipality by municipality it might be an idea to identify those 
municipalities that do not have suitable open data through stats canada.  I can 
see us with a list of municipalities and a data source and I think it probably 
should be in one place.

Cheerio John

On Fri, 3 Jan 2020 at 15:42, Daniel @jfd553 
mailto:jfd...@hotmail.com>> wrote:
Bonjour groupe, mes excuses pour ce très long courriel !-)
I have reviewed everything that has been written on the ODB import (aka Canada 
Building Import) in Talk-ca and the wiki. I proposed changes to some wiki pages 
(via talk tabs) to ease the discussions about this import and the following. 
Now, in order to restart the import, here are some thoughts and a proposal on 
how to proceed to complete the task.

1. Issues with the ODB Data Import
Many concerns were raised about the import. One major concern was to obtain 
local communities’ buy-in in the Canadian context. Another concern was to 
improve the quality of the data prior the import. The following paragraphs 
intend to clear most of these concerns.
1.1. Which data import project?
According to the import guidelines (steps 3 & 4), a data import explicitly 
refers to a single data source (ODB in our case). Discussions about the 
availability and quality of Microsoft or ESRI data, while interesting, are not 
relevant as they should be dealt with as other import projects.
1.2. What has been imported so far?
According to what I found [1], the ODB import is completed for 21 
municipalities. These imports seem to have kept OSM content’s history, at least 
for the samples checked, but many problems were found. In some case, the 
imports brought swimming pools in OSM because they were included in the dataset 
(e.g. Moncton). In other cases, importing buildings with accurate locations 
(XY) over content mapped from less accurate imagery resulted in buildings that 
now overlap the street network (e.g. Squamish). It means that all these 21 
imports need to be carefully re-examined and corrected as required.
For 12 other municipalities, the import is partial, either suspended as 
requested, or because previous imports had already provided most of the 
buildings (often from the same municipal provider). That said the import will 
definitely improve OSM accuracy and completeness if done properly.
2. How should ODB Data be imported?
I will copy the following paragraphs in the “Canada Building Import” wiki page 
[3] for a detailed discussion…
Since the data (ODB, OSM and imagery) differ from one municipality to another, 
there can be no imports at the national or provincial level. We have to work on 
a municipal basis and make sure to identify all the problems and the corrective 
measures to apply when dealing with issues like those I identified [1].
2.1 Importing Locally
According to the import guidelines (step 2), we must not import the data 
without local buy-in. However, and contrarily to some European country, there 
is usually no such thing as a local OSM community in each municipality. 
However, we may find a few local mappers from time to time. Working on a 
municipal basis should allow identifying these local mappers before doing the 
import. I often use this tool [2] to identify and contact local mappers. Once 
identified, I suggest that…
- We contact them to explain our intents by referring to appropriate wiki pages.
- We wait a week or two to let them respond nothing, that they have concerns, 
or wish to help.
- Without negative answers we could proceed to the import.
I first suggest that when a contributor wishes to import ODB for a given 
municipality, he first identifies himself as responsible for the import (we 
need to create an entry for each municipality somewhere in the wiki). He can 
then contact local mappers, as explain above, and go ahead with the import once 
everything settled. For those who already made the import, I suggest that they 
review their work since many issues were detected with some of these imports.
Since there are only a few local OSM communities in Canada, and because Canada 
is large,

Re: [Talk-ca] Importing buildings in Canada

2020-01-03 Diskussionsfäden Daniel @jfd553

Hi John,
To comply with the import directive, I would like the discussion to continue on 
the current ODB import only. Could we talk about other sources of potential 
imports at another time? -)

Thanks
Daniel
From: john whelan [mailto:jwhelan0...@gmail.com]
Sent: Friday, January 03, 2020 15:57
To: Daniel @jfd553
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Importing buildings in Canada

Sounds sane to me.

Are we thinking of setting up a second import to handle Microsoft building 
outlines on a similar basis? Or extending this one?  I only ask since if we are 
doing it municipality by municipality it might be an idea to identify those 
municipalities that do not have suitable open data through stats canada.  I can 
see us with a list of municipalities and a data source and I think it probably 
should be in one place.

Cheerio John

On Fri, 3 Jan 2020 at 15:42, Daniel @jfd553 
mailto:jfd...@hotmail.com>> wrote:
Bonjour groupe, mes excuses pour ce très long courriel !-)
I have reviewed everything that has been written on the ODB import (aka Canada 
Building Import) in Talk-ca and the wiki. I proposed changes to some wiki pages 
(via talk tabs) to ease the discussions about this import and the following. 
Now, in order to restart the import, here are some thoughts and a proposal on 
how to proceed to complete the task.

1. Issues with the ODB Data Import
Many concerns were raised about the import. One major concern was to obtain 
local communities’ buy-in in the Canadian context. Another concern was to 
improve the quality of the data prior the import. The following paragraphs 
intend to clear most of these concerns.
1.1. Which data import project?
According to the import guidelines (steps 3 & 4), a data import explicitly 
refers to a single data source (ODB in our case). Discussions about the 
availability and quality of Microsoft or ESRI data, while interesting, are not 
relevant as they should be dealt with as other import projects.
1.2. What has been imported so far?
According to what I found [1], the ODB import is completed for 21 
municipalities. These imports seem to have kept OSM content’s history, at least 
for the samples checked, but many problems were found. In some case, the 
imports brought swimming pools in OSM because they were included in the dataset 
(e.g. Moncton). In other cases, importing buildings with accurate locations 
(XY) over content mapped from less accurate imagery resulted in buildings that 
now overlap the street network (e.g. Squamish). It means that all these 21 
imports need to be carefully re-examined and corrected as required.
For 12 other municipalities, the import is partial, either suspended as 
requested, or because previous imports had already provided most of the 
buildings (often from the same municipal provider). That said the import will 
definitely improve OSM accuracy and completeness if done properly.
2. How should ODB Data be imported?
I will copy the following paragraphs in the “Canada Building Import” wiki page 
[3] for a detailed discussion…
Since the data (ODB, OSM and imagery) differ from one municipality to another, 
there can be no imports at the national or provincial level. We have to work on 
a municipal basis and make sure to identify all the problems and the corrective 
measures to apply when dealing with issues like those I identified [1].
2.1 Importing Locally
According to the import guidelines (step 2), we must not import the data 
without local buy-in. However, and contrarily to some European country, there 
is usually no such thing as a local OSM community in each municipality. 
However, we may find a few local mappers from time to time. Working on a 
municipal basis should allow identifying these local mappers before doing the 
import. I often use this tool [2] to identify and contact local mappers. Once 
identified, I suggest that…
- We contact them to explain our intents by referring to appropriate wiki pages.
- We wait a week or two to let them respond nothing, that they have concerns, 
or wish to help.
- Without negative answers we could proceed to the import.
I first suggest that when a contributor wishes to import ODB for a given 
municipality, he first identifies himself as responsible for the import (we 
need to create an entry for each municipality somewhere in the wiki). He can 
then contact local mappers, as explain above, and go ahead with the import once 
everything settled. For those who already made the import, I suggest that they 
review their work since many issues were detected with some of these imports.
Since there are only a few local OSM communities in Canada, and because Canada 
is large, I suggest not limiting the import of a given municipality to the 
people of the concerned province or region.
2.2 Pre-processing
Once local mappers have agreed, some pre-processing can be done if required.
A few months ago, I developed a tool that could be used to process the data 
[4]. Concerns were raised because the

Re: [Talk-ca] Importing buildings in Canada

2020-01-03 Diskussionsfäden john whelan

Sounds sane to me.

Are we thinking of setting up a second import to handle Microsoft building
outlines on a similar basis? Or extending this one?  I only ask since if we
are doing it municipality by municipality it might be an idea to identify
those municipalities that do not have suitable open data through stats
canada.  I can see us with a list of municipalities and a data source and I
think it probably should be in one place.

Cheerio John

On Fri, 3 Jan 2020 at 15:42, Daniel @jfd553  wrote:

> Bonjour groupe, mes excuses pour ce très long courriel !-)
>
> I have reviewed everything that has been written on the ODB import (aka
> Canada Building Import) in Talk-ca and the wiki. I proposed changes to some
> wiki pages (via talk tabs) to ease the discussions about this import and
> the following. Now, in order to restart the import, here are some thoughts
> and a proposal on how to proceed to complete the task.
>
>
>
> *1. Issues with the ODB Data Import*
>
> Many concerns were raised about the import. One major concern was to
> obtain local communities’ buy-in in the Canadian context. Another concern
> was to improve the quality of the data prior the import. The following
> paragraphs intend to clear most of these concerns.
>
> *1.1. Which data import project?*
>
> According to the import guidelines (steps 3 & 4), a data import explicitly
> refers to a single data source (ODB in our case). Discussions about the
> availability and quality of Microsoft or ESRI data, while interesting, are
> not relevant as they should be dealt with as other import projects.
>
> *1.2. What has been imported so far?*
>
> According to what I found [1], the ODB import is completed for 21
> municipalities. These imports seem to have kept OSM content’s history, at
> least for the samples checked, but many problems were found. In some case,
> the imports brought swimming pools in OSM because they were included in the
> dataset (e.g. Moncton). In other cases, importing buildings with accurate
> locations (XY) over content mapped from less accurate imagery resulted in
> buildings that now overlap the street network (e.g. Squamish). It means
> that all these 21 imports need to be carefully re-examined and corrected as
> required.
>
> For 12 other municipalities, the import is partial, either suspended as
> requested, or because previous imports had already provided most of the
> buildings (often from the same municipal provider). That said the import
> will definitely improve OSM accuracy and completeness if done properly.
>
> *2. How should ODB Data be imported?*
>
> I will copy the following paragraphs in the “Canada Building Import” wiki
> page [3] for a detailed discussion…
>
> Since the data (ODB, OSM and imagery) differ from one municipality to
> another, there can be no imports at the national or provincial level. We
> have to work on a municipal basis and make sure to identify all the
> problems and the corrective measures to apply when dealing with issues like
> those I identified [1].
>
> *2.1 Importing Locally*
>
> According to the import guidelines (step 2), we must not import the data
> without local buy-in. However, and contrarily to some European country,
> there is usually no such thing as a local OSM community in each
> municipality. However, we may find a few local mappers from time to time.
> Working on a municipal basis should allow identifying these local mappers
> before doing the import. I often use this tool [2] to identify and contact
> local mappers. Once identified, I suggest that…
>
> - We contact them to explain our intents by referring to appropriate wiki
> pages.
>
> - We wait a week or two to let them respond nothing, that they have
> concerns, or wish to help.
>
> - Without negative answers we could proceed to the import.
>
> I first suggest that when a contributor wishes to import ODB for a given
> municipality, he first identifies himself as responsible for the import (we
> need to create an entry for each municipality somewhere in the wiki). He
> can then contact local mappers, as explain above, and go ahead with the
> import once everything settled. For those who already made the import, I
> suggest that they review their work since many issues were detected with
> some of these imports.
>
> Since there are only a few local OSM communities in Canada, and because
> Canada is large, I suggest not limiting the import of a given municipality
> to the people of the concerned province or region.
>
> *2.2 Pre-processing*
>
> Once local mappers have agreed, some pre-processing can be done if
> required.
>
> A few months ago, I developed a tool that could be used to process the
> data [4]. Concerns were raised because the application was developed using
> proprietary software. So I documented the whole process and algorithms in
> order to see courageous coders converting it in open source software. In
> the meantime, and as long as I have access to an FME licence, I could
> process the data, when

Re: [OSM-talk-fr] Chemins publics / privés / ouverts / fermés

2020-01-03 Diskussionsfäden ades.s...@orange.fr

Il y a un chemin ou pas ! sur le terrain, pas sur bing ou l'ortho ign !
Si il y en a un, soit il est utilisable par tout un chacun, soit il ne l'est 
pas. Dans le premier cas rien à rajouter sauf les éventuelles restrictions 
habituelles :  bourrin, mobylette, piéton etc.
S'il n'est pas utilisable, à part 'access:no' ou 'private', je ne vois pas trop 
quoi rajouter. En plus je ne suis pas certain que 'private' veuille dire 
'privé' en français,mais je ne cause pas le langage des grandes dents.
Que le terrain d'assiette relève d'une propriété publique ou d'une propriété 
privée ne change rien et en plus ce n'est pas visible sur le terrain.
En outre comment on fait si le terrain appartient au domaine privé de l'État ou 
d'une collectivité territoriale ? 

> Le 3 janv. 2020 à 20:58, Florimond Berthoux  a 
> écrit :
> 
> Bonsoir,
> 
> La réalité du terrain prime,
> 
> Le ven. 3 janv. 2020 à 17:38, Arnaud Champollion
>  a écrit :
>> 1) le cas du chemin situé sur parcelle privée, et d'accès privé.
>> 
>> 2) le cas du chemin situé sur parcelle privée, mais passage autorisé
>> (c'est le cas concrètement de beaucoup de sentiers de randonnée)
>> 
>> 3) le cas du chemin situé sur parcelle publique, et d'accès autorisé
>> 
>> 4) le cas du chemin situé sur parcelle publique, mais "accaparé" par le
>> propriétaire mitoyen
>> 
>> Je me pose plusieurs questions sur la façon de bien cartographier.
>> 
>> --> Cas numéro 1 : ce genre de chemin doit-il figurer sur la carte ? Au
>> même titre que des allés situées à l'intérieur de pripriétés ? Avec le
>> tag access=private ?
> 
> Oui, ils peuvent être modélisés et avec access=private.
> 
>> --> Cas numéro 4 : du point de vue du terrain concret, ce serait
>> access=private , du point de vue légal ce serait access=yes donc on
>> privilégie quoi ?
> 
> La réalité du terrain, le fait que ça soit sur parcelle publique est
> difficile (impossible ?) à deviner sur le terrain.
> Si l'accès est physiquement restreint où qu'il y a un panneau "privés"
> c'est que ça doit être modéliser ainsi avec access=private, barrier et
> autres.
> OpenStreetMap n'est pas là pour contester ou résoudre des problèmes
> d'ordre judiciaire ;)
> 
> Et pour l'information d'accaparement j'ai du mal à voir comment ça
> pourrait être une donnée objective constatable sur le terrain.
> À supprimer pour moi.
> 
> 
> -- 
> Florimond Berthoux
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [Talk-ca] Importing buildings in Canada

2020-01-03 Diskussionsfäden Daniel @jfd553

Bonjour groupe, mes excuses pour ce très long courriel !-)
I have reviewed everything that has been written on the ODB import (aka Canada 
Building Import) in Talk-ca and the wiki. I proposed changes to some wiki pages 
(via talk tabs) to ease the discussions about this import and the following. 
Now, in order to restart the import, here are some thoughts and a proposal on 
how to proceed to complete the task.

1. Issues with the ODB Data Import
Many concerns were raised about the import. One major concern was to obtain 
local communities' buy-in in the Canadian context. Another concern was to 
improve the quality of the data prior the import. The following paragraphs 
intend to clear most of these concerns.
1.1. Which data import project?
According to the import guidelines (steps 3 & 4), a data import explicitly 
refers to a single data source (ODB in our case). Discussions about the 
availability and quality of Microsoft or ESRI data, while interesting, are not 
relevant as they should be dealt with as other import projects.
1.2. What has been imported so far?
According to what I found [1], the ODB import is completed for 21 
municipalities. These imports seem to have kept OSM content's history, at least 
for the samples checked, but many problems were found. In some case, the 
imports brought swimming pools in OSM because they were included in the dataset 
(e.g. Moncton). In other cases, importing buildings with accurate locations 
(XY) over content mapped from less accurate imagery resulted in buildings that 
now overlap the street network (e.g. Squamish). It means that all these 21 
imports need to be carefully re-examined and corrected as required.
For 12 other municipalities, the import is partial, either suspended as 
requested, or because previous imports had already provided most of the 
buildings (often from the same municipal provider). That said the import will 
definitely improve OSM accuracy and completeness if done properly.
2. How should ODB Data be imported?
I will copy the following paragraphs in the "Canada Building Import" wiki page 
[3] for a detailed discussion...
Since the data (ODB, OSM and imagery) differ from one municipality to another, 
there can be no imports at the national or provincial level. We have to work on 
a municipal basis and make sure to identify all the problems and the corrective 
measures to apply when dealing with issues like those I identified [1].
2.1 Importing Locally
According to the import guidelines (step 2), we must not import the data 
without local buy-in. However, and contrarily to some European country, there 
is usually no such thing as a local OSM community in each municipality. 
However, we may find a few local mappers from time to time. Working on a 
municipal basis should allow identifying these local mappers before doing the 
import. I often use this tool [2] to identify and contact local mappers. Once 
identified, I suggest that...
- We contact them to explain our intents by referring to appropriate wiki pages.
- We wait a week or two to let them respond nothing, that they have concerns, 
or wish to help.
- Without negative answers we could proceed to the import.
I first suggest that when a contributor wishes to import ODB for a given 
municipality, he first identifies himself as responsible for the import (we 
need to create an entry for each municipality somewhere in the wiki). He can 
then contact local mappers, as explain above, and go ahead with the import once 
everything settled. For those who already made the import, I suggest that they 
review their work since many issues were detected with some of these imports.
Since there are only a few local OSM communities in Canada, and because Canada 
is large, I suggest not limiting the import of a given municipality to the 
people of the concerned province or region.
2.2 Pre-processing
Once local mappers have agreed, some pre-processing can be done if required.
A few months ago, I developed a tool that could be used to process the data 
[4]. Concerns were raised because the application was developed using 
proprietary software. So I documented the whole process and algorithms in order 
to see courageous coders converting it in open source software. In the 
meantime, and as long as I have access to an FME licence, I could process the 
data, when necessary, prior to make it available through the task manager.
Proposed pre-processing [4] includes:
- Reading of original ODB data,
- Removal of near collinear nodes (simplification),
- Orthogonalization of buildings (for corners having near right angles),
- Tagging of building footprints,
- Providing files in OSM format.
Proposed tagging: In addition to the tags produced by the orthogonalization 
process [4] and the source tag 
(source=Statistics Canada - 
Open Building Database), the name of the Census Subdivision provided in ODB 
data [5] is used to add the addr:city tag to each building.
The

Re: [OSM-talk-fr] Chemins publics / privés / ouverts / fermés

2020-01-03 Diskussionsfäden Florimond Berthoux

Bonsoir,

La réalité du terrain prime,

Le ven. 3 janv. 2020 à 17:38, Arnaud Champollion
 a écrit :
> 1) le cas du chemin situé sur parcelle privée, et d'accès privé.
>
> 2) le cas du chemin situé sur parcelle privée, mais passage autorisé
> (c'est le cas concrètement de beaucoup de sentiers de randonnée)
>
> 3) le cas du chemin situé sur parcelle publique, et d'accès autorisé
>
> 4) le cas du chemin situé sur parcelle publique, mais "accaparé" par le
> propriétaire mitoyen
>
> Je me pose plusieurs questions sur la façon de bien cartographier.
>
> --> Cas numéro 1 : ce genre de chemin doit-il figurer sur la carte ? Au
> même titre que des allés situées à l'intérieur de pripriétés ? Avec le
> tag access=private ?

Oui, ils peuvent être modélisés et avec access=private.

> --> Cas numéro 4 : du point de vue du terrain concret, ce serait
> access=private , du point de vue légal ce serait access=yes donc on
> privilégie quoi ?

La réalité du terrain, le fait que ça soit sur parcelle publique est
difficile (impossible ?) à deviner sur le terrain.
Si l'accès est physiquement restreint où qu'il y a un panneau "privés"
c'est que ça doit être modéliser ainsi avec access=private, barrier et
autres.
OpenStreetMap n'est pas là pour contester ou résoudre des problèmes
d'ordre judiciaire ;)

Et pour l'information d'accaparement j'ai du mal à voir comment ça
pourrait être une donnée objective constatable sur le terrain.
À supprimer pour moi.


-- 
Florimond Berthoux

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

Re: [OSM-talk-fr] SPAM, Re: SPAM, Re: Chemins publics / privés / ouverts / fermés


Le 03/01/2020 à 20:12, Philippe Verdy a écrit :
La présence d'un numéro n'indique donc pas si la parcelle est publique 
ou privée.



OK, mais du coup, l'absence de numéro permet-il de dire que la parcelle 
est publique ?



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

Re: [Talk-us] Jefferson Notch Road and latest "GPS made me do it" in the news

2020-01-03 Diskussionsfäden Kevin Broderick

However, that assumes that you can trust the news to be accurate, and the
distinction between "closed in winter" and "not maintained for winter
travel" is not one I expect the news media to get right. The article I saw
quoted the driver has having seen a "Not maintained for winter travel" sign
and continuing because he didn't think that implied a closure (which is
true, even if it may be a poor choice in a minivan).

Given that it is a snowmachine trail, "closed" seems more likely (and it
would be exceedingly impolite to put wheel ruts into a groomed trail, even
if legal), but it's been long enough since I traveled it that I can't
recall the signage. My fuzzy recollection is a gate on the Base Station
end. I can't find a definitive answer on the NH DOT site, and the WMNF MVUM
shows it to be a non-forest road through the forest.

On Fri, Jan 3, 2020 at 2:11 PM Mark Wagner  wrote:

> On Thu, 2 Jan 2020 14:47:35 -0500
> Bill Ricker  wrote:
>
> > Kevin asks,
> > > is Jefferson Notch Road actually closed to wheeled vehicles in
> > > winter or
> > just not maintained?
> >
> > Per copyright news reports, it is signed as closed to wheeled
> > vehicles, open to snow-machines only, in winter.
> > (As should be obvious, to correctly tag this according to our
> > license, we do need some on-the ground or license0compatible
> > verification of the facts form the news, as well as a decision on
> > what tags to use.)
>
> In the United States, facts can't be copyrighted, only specific ways of
> expressing them.  If a news article says "the road is closed in the
> winter from Wherezit Junction to Anytown", you can freely extract the
> fact of the closure, look for the OSM ways corresponding to the
> description, and apply a "closed in the winter" tag.
>
> (If the news article instead has a map of the closure, the copyright
> situation becomes more questionable, because now you're copying not
> just the facts of the closure, but possibly the way they're expressed
> as well.)
>
> --
> Mark
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>

-- 
Kevin Broderick
k...@kevinbroderick.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] SPAM, Re: Chemins publics / privés / ouverts / fermés

2020-01-03 Diskussionsfäden Philippe Verdy

Tout à fait , la parcelle a pu historiquement être privée avant son
acquisition par la collectivité elle a été numérotée et son numéro
conservé. Souvent aussi une parcelle doit être divisée pour des
acquisitions publiques, le fragment reçoit un numéro, l'acte administratif
ou notarié peut distinguer alors les deux fragments. Demême pour le
réaménagement de routes, il est souvent nécessaire d'acquérir des fragments
mais en échange la colelctivité peut céder des fragments que la route n'a
plus besoin d'utiliser, en procédant à un échange (la collectivité se
chargeant des travaux de dégagement de l'ancienne voirie.

La présence d'un numéro n'indique donc pas si la parcelle est publique ou
privée. D'autre part il y a tout le problème des droits de passage: les
chemins peuvent être privés, sur une parcelle privée ou publique, mais il y
a un accès autorisé pour les résidents ou pour tout le monde (bordures de
rivières accès aux plages) ou doit être conservé accessible par les
propriétaires pour des questions de sécurité (accès pour les services
d'urgence ou en cas de crue sur la voie publique. Les propriétaires ont la
charge de tenir le chemin en état (peu le font et certains abusent des
chemins publics pour les bloquer par des barrières ou monceaux de
gravas/détritus) Les drotis de passage soint des cas fréquents de conflits
de voisinage (et souvent les communes interviennent peu, elles renvoient
les résidents ou passants concernés à la force publique qui ne se déplace
pas ou ira seulement constater le blocage). Au final il n'y a que quand
survient un problème de sécurité grave que la collectivité intervient (elle
peut faire les travaux de dégagements à la place des propriétaires, mais
les facturer, elle peut aussi prendre ça à sa charge si l'usage public du
chemin privé a causé des dommages ou dégradations, mais la plupart du
tempos c'est aux propriétaires ou locataires de faire appel à la force
publique ou faire constater par un huissier avant une procédure judiciaire,
qui peut mettre des années et provoquer de graves troubles de voisinage).

De toute façon on ne peut pas faire tout ce qu'on veut sur sa propriété, on
doit toujours négocier avec le voisinage et pour les travaux touchant ou
immobilisant le sol ou changeant sa couverture naturelle ou artificielle,
obtenir les permis nécessaires et l'aspect visible du domaine public est
aussi important que les nuisances au voisinage et à l'environnement. On
peut planter un arbre presque comme on veut mais pas l'abattre s'il
bordeune limite de propriété, même si on a un permis de construire et que
l'arbre gêne la construction (par ses racines ou parce qu'il penche et
menace de tomber).


Le ven. 3 janv. 2020 à 18:57, Arnaud Champollion <
arnaud.champoll...@linux-alpes.org> a écrit :

> Le 03/01/2020 à 18:24, deuzeffe a écrit :
>
>
> Le chemin à l'ouest est sur une parcelle numérotée 148, donc a priori il
> est privé.
>
> Le chemin à l'est n'a pas de numéro, donc a priori il est communal, et
> c'est un accaparement par le propriétaire mitoyen.
>
>
> Petit bémol : les communes ont le droit d'être propriétaire de parcelles
> cadastrées avec des "chemins" qui en font partie ;)
>
>
> En effet, la parcelle numérotée peut être communale aussi dans ce cas-là.
>
> Ce qui est sûr c'est que la zone sans numéro est communale, elle.
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Jefferson Notch Road and latest "GPS made me do it" in the news

2020-01-03 Diskussionsfäden Mark Wagner

On Thu, 2 Jan 2020 14:47:35 -0500
Bill Ricker  wrote:

> Kevin asks,
> > is Jefferson Notch Road actually closed to wheeled vehicles in
> > winter or  
> just not maintained?
> 
> Per copyright news reports, it is signed as closed to wheeled
> vehicles, open to snow-machines only, in winter.
> (As should be obvious, to correctly tag this according to our
> license, we do need some on-the ground or license0compatible
> verification of the facts form the news, as well as a decision on
> what tags to use.)

In the United States, facts can't be copyrighted, only specific ways of
expressing them.  If a news article says "the road is closed in the
winter from Wherezit Junction to Anytown", you can freely extract the
fact of the closure, look for the OSM ways corresponding to the
description, and apply a "closed in the winter" tag.

(If the news article instead has a map of the closure, the copyright
situation becomes more questionable, because now you're copying not
just the facts of the closure, but possibly the way they're expressed
as well.)

-- 
Mark

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

[OSM-talk] JOSM: Display time of a gpx track

2020-01-03 Diskussionsfäden tshrub


hi,
if I load gpx data as layer, how can I see the points & time from those?
With an extension I can see heights, that's fine.
Is there anything similar for the time - maybe popup-like when moving 
the mouse over it?

regards


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

Re: [OSM-co] Retos de MapRoulette para Colombia

2020-01-03 Diskussionsfäden Andrew Wiseman via Talk-co

Saludos,

Actualicé los retos con datos nuevos para Colombia. Hay una pagina aquí con 
todos los retos incluyendo caminos cruzando, carreteras flotantes, vías 
superpuestas, problemas de enrutamiento y otros. También hay un reto nuevo 
sobre inconsistencias de ortografía del nombre del camino -- cuando vías 
conectadas tienen nombres similares.

https://maproulette.org/browse/projects/38984 


Muchas gracias,

Andrew 


Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 


> On Jul 23, 2019, at 11:57 AM, Andrew Wiseman via Talk-co 
>  wrote:
> 
> Hola,
> 
> He publicado otro reto de MapRoulette, para las líneas de costa en Colombia. 
> Esta reto busca partes de la costa que están muy largas o con esquinas 
> agudos, que pueden deberse a digitalización inexacta o a muy pocos vértices o 
> esquinas como sea necesario. Hay más detalles y instrucciones en el reto: 
> https://maproulette.org/challenge/8251 
> 
> 
> Por favor, hágamelo saber si tiene alguna pregunta o comentario. 
> 
> Saludos,
> 
> Andrew
> 
> 
> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
> 
> 
>> On Dec 12, 2018, at 6:27 PM, Andrew Wiseman > > wrote:
>> 
>> Hola OSM Colombia,
>> 
>> Esto es Andrew del equipo de mapas de Apple. Llevamos algún tiempo 
>> trabajando en el red vial (https://github.com/osmlab/appledata/issues/43 
>> ) y recientemente usado 
>> nuestro herramienta Atlas para análisis de datos 
>> (https://github.com/osmlab/atlas ) para 
>> buscar algunos tipos de posibles problemas, como carreteras con ángulos 
>> agudos, intersecciones de edificios y carreteras, y lugares donde la 
>> clasificación de “highway_link” no coincide con la clasificación más alta de 
>> las carreteras. Pongo los resultados de los retos en MapRoulette, un 
>> herramienta que te permite pasar los problemas uno por uno y corregirlos o 
>> marcar que no son un problema. Quería hacerles saber que estaban disponibles 
>> en caso de que alguien quisiera intentar arreglarlos. Yo también arreglaré 
>> algunos.
>> 
>> En MapRoulette escoges un problema random o haz clic en un problema 
>> especifico. Si desea ver tareas en un lugar determinado, como en un lugar 
>> con el que está familiarizado, puede hacer clic en "más opciones" y luego en 
>> “load tasks by proximity” (cargar tareas por proximidad.)
>> 
>> Por favor, hágamelo saber si tiene alguna pregunta o comentario.
>> 
>> Los retos son:
>> 
>> Intersecciones de edificios y carreteras en Colombia (a cerca de Bogotá): 
>> https://maproulette.org/mr3/browse/challenges/3389 
>> 
>> Carreteras de ángulo agudo en Colombia: 
>> https://maproulette.org/mr3/browse/challenges/3358 
>> 
>> Carreteras de enlaces en Colombia: 
>> https://maproulette.org/mr3/browse/challenges/3355 
>> 
>> 
>> Muchas gracias,
>> 
>> Andrew
>> 
>> 
>> Andrew Wiseman |  Maps | andrew_wise...@apple.com 
>> 
> 
> ___
> Talk-co mailing list
> Talk-co@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-co

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

[OSM-talk] JOSM: Uhrzeit einer gpx-Strecke anzeigen

2020-01-03 Diskussionsfäden tshrub


hi,
wenn ich gpx-Daten als Ebene lade, wie kann ich von denen die Punkte mit 
Uhrzeit sehen?

Mit einer Erweiterung kann ich Höhen sehen, das ist schon gut.
Gibts Ähnliches für die Uhrzeit - vielleicht PopUp-mäßig beim 
Mausüberfahren?

 Grüße


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

Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir

2020-01-03 Diskussionsfäden Christian Rogel

> Le 3 janv. 2020 à 00:20, Jérôme Amagat  a écrit :
> 
> Oui pour virer les point cardinaux mais il n'y en a d'autres que je n'aime 
> pas. Qui sont là juste pour remplir le cadastre avec des lieu dit.
> "sous un autre lieu dit", les prés de un autre lieu dit" ... peut être que 
> parfois ça a vraiment une utilité mais pour moi c'est la même chose que les 
> points cardinaux.
> "Le bourg"  si c'est le village de la commune, il faut mettre son nom pas 
> besoin d'un lieu dit qui porte le nom "le bourg"
> "Le château", quand le château existe encore et que le terme désigne 
> seulement ce château, il faut mettre les bons tags et nom sur le bâtiment 
> mais pas besoin d'ajouter un lieu dit.
> Pareil pour les moulins (et sûrement d'autres choses du même style)


Agaçants de voir parler des lieux-dit sans les qualifier :

Il y a des lieux-dits qui sont des noms de parcelle, d’autres des noms de 
regroupement de parcelles (c’est de la microtoponymie) et d’autres qui sont des 
lieux-dits habités (écarts ou quartiers ou habitat aggloméré).
Ils portent des noms vulgaires ou officiels comme alpage, prairie, campagne, 
borie, ferme, mouin, hameau,lotissement, bourg, village, ville, agglomération, 
etc.

Ce qui est certain, c’est que bannir les lieux-dits non habités est imprudent, 
d’une part, parce que, même les habitants ne sont pas aptes à mesurer leur 
usage, qui subsiste au moins dans beaucoup d’actes administratifs et que les 
liens parfois ténus qu’il y a entre eux et les adresses mérite d’être conservé.
Je me souviens d’une intervention au SotM FR de Brest (2015) par laquelle les 
représentants du Collectif des Garrigues (Gard) expliquaient leur attachement à 
transcrire la microtoponymie  dans OSM.

Conformément à l’esprit de base d’OSM, que ceux qui ne sont pas motivés par la 
microtoponymie n’en mettent pas.


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

Re: [OSM-talk-fr] SPAM, Re: Chemins publics / privés / ouverts / fermés

2020-01-03 Diskussionsfäden Andrew Wiseman por (Talk-br)


Le 03/01/2020 à 18:24, deuzeffe a écrit :


Le chemin à l'ouest est sur une parcelle numérotée 148, donc a priori 
il est privé.


Le chemin à l'est n'a pas de numéro, donc a priori il est communal, 
et c'est un accaparement par le propriétaire mitoyen.


Petit bémol : les communes ont le droit d'être propriétaire de 
parcelles cadastrées avec des "chemins" qui en font partie ;)


En effet, la parcelle numérotée peut être communale aussi dans ce cas-là.

Ce qui est sûr c'est que la zone sans numéro est communale, elle.




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

Re: [OSM-talk-fr] pb sur un cset lié aux langues locales

2020-01-03 Diskussionsfäden Christian Rogel

> Le 2 janv. 2020 à 16:34, Landry Breuil  a écrit :
> pas fait d'OSM depuis un bail, mais en me promenant dans un coin que je
> connais bien (lieu dit nommé 'le pous' ou 'lou pous' sur les panneaux
> sur place), dans osmand (et sur la carte d'osm.org) j'ai eu la surprise
> de voir 'Le Potz' qui est un nom completement inconnu sur place. - le
> nom était correct pour moi auparavant (cf
> https://www.openstreetmap.org/node/2077266629/history il y'a 8 mois), et
> a été modifié par oc-OpenStreetMap dans le changeset
> https://www.openstreetmap.org/changeset/70878777 .

J’ai passé l’information au président de l’IEO qui m’indique qu’il s’agirait 
d’une mauvaise manip
accompagnant un sourçage, mais, sans aucune intention de corriger les « name ».

L’examen du cadastre à travers ID et en activant BANO a de quoi troubler :
- Lou Pous est le lieu BANO avec un n° Fantoir et apparaît en rouge
- Le Potz apparaît en vert à l’écart du hameau
- Mais, c’est ce qui est écrit dans le name:fr, Le Puits, qui s’affiche sur OSM

Pour moi, on devrait avoir :

name = Lou Pous
alt_name = Le Potz
name:oc = Lo Potz


Pas besoin de name:fr = Le Puits qui est faux et perturbe.



Christian R.






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

Re: [Talk-br] Desafios MapRoulette no Brasil

Olá OSM Brasil. 

Coloquei todos os desafios ativos do MapRoulette que criei para o Brasil neste 
projeto, para que você possa acessá-los facilmente: Brasil - todos os desafios 
ativos: https://maproulette.org/browse/projects/38970 

Eles são principalmente redes rodoviárias problemas, além de questões costeiras 
e cidades desaparecidas de Pascal Neis.

Obrigado,

Andrew


Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 


> On Sep 3, 2019, at 2:49 PM, Andrew Wiseman  wrote:
> 
> Olá OSM Brasil,
> 
> Publiquei mais desafios do MapRoulette, que tratam de estradas e rotas. 
> Alguns deles são atualizações dos desafios que eu postei antes.
> 
> Áreas de roteamento impossíveis: 
> https://maproulette.org/browse/challenges/8655 
>  
> Ângulos agudos da estrada: https://maproulette.org/browse/challenges/8652 
>  
> Restrições de turno inválidas: https://maproulette.org/browse/challenges/8660 
>  
> Estradas desconectadas ou flutuantes: 
> https://maproulette.org/browse/challenges/8649 
>  
> Cruzando estradas: https://maproulette.org/browse/challenges/8659 
>  
> Verificação de conectividade: https://maproulette.org/browse/challenges/8657 
>  
> Verificação do link da estrada: 
> https://maproulette.org/browse/challenges/8654 
>  
> Rotatórias malformadas: https://maproulette.org/browse/challenges/8650 
>  
> 
> Entre em contato se tiver alguma dúvida ou comentário.
> 
> Obrigado,
> 
> Andrew
> 
> 
> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
> 
> 
>> On Jul 29, 2019, at 10:34 AM, Andrew Wiseman por (Talk-br) 
>> mailto:talk-br@openstreetmap.org>> wrote:
>> 
>> Olá OSM Brasil
>> 
>> Eu publiquei um novo desafio MapRoulette, que analisa linhas costeiras que 
>> podem ser muito longas ou com ângulos agudos. Estes podem ter sido 
>> digitalizados mal ou com imagens antigas. Há mais detalhes e instruções 
>> sobre o desafio: https://maproulette.org/challenge/8267 
>> 
>> 
>> Deixe-me saber se você tiver alguma dúvida or feedback.
>> 
>> Obrigado,
>> 
>> Andrew
>> 
>> 
>> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
>> 
>> 
>>> On Feb 26, 2019, at 11:31 AM, Andrew Wiseman por (Talk-br) 
>>> mailto:talk-br@openstreetmap.org>> wrote:
>>> 
>>> Olá OSM Brasil
>>>  
>>> Eu sou Andrew Wiseman do Maps time da Apple. Recentemente, usamos nossa 
>>> ferramenta de análise de dados Atlas (https://github.com/osmlab/atlas 
>>> ) para examinar alguns tipos de problemas 
>>> possíveis, como intercessão de construções com estradas, vias de acesso à 
>>> rodovias que não têm as classificações corretas, formas sobrepostas 
>>> (geralmente estradas duplicadas) e ângulos da estrada que são muito agudos. 
>>> Eu postei os resultados dessas verificações no MapRoulette, uma ferramenta 
>>> que permite que você passe por possíveis problemas um por um e os corrija 
>>> ou indique que eles não são um problema. Eu queria que você soubesse que 
>>> eles estão disponíveis no caso de outros quererem tentar consertar alguns 
>>> deles - eu também pretendo passar por alguns deles.
>>>  
>>> No MapRoulette você pode escolher uma tarefa aleatória para corrigir ou 
>>> clicar em uma específica. Se você quiser executar tarefas em um determinado 
>>> local, como em algum lugar com o qual esteja familiarizado, clique em "mais 
>>> opções" e em "carregar tarefas por proximidade".
>>>  
>>> As verificações são:
>>>  
>>> - Ângulos agudos: https://maproulette.org/mr3/challenge 
>>> /3666
>>> - Vias de acesso à rodovias: https://maproulette.org/mr3/challenge 
>>> /3667
>>> - Interseções construção-estrada: https://maproulette.org/mr3/challenge 
>>> /3669
>>> - Formas sobrepostas: https://maproulette.org/mr3/challenge 
>>> /3668
>>>  
>>> Por favor, deixe-me saber se você tem alguma dúvida ou feedback.
>>>  
>>> Obrigado,
>>>  
>>> Andrew
>>> 
>>> //
>>> 
>>> Hello OSM Brazil,
>>> 
>>> I’m Andrew Wiseman with Apple’s Maps team. We recently used our Atlas data 
>>> analysis tool (https://github.com/osmlab/atlas 
>>> ) to look at a few types of potential 
>>> issues, such as building-road intersections, highway link roads that don’t 
>>> have the correct classifications, overlapping ways (usually duplicated 
>>> roads) and road angles

Re: [OSM-talk-fr] Chemins publics / privés / ouverts / fermés

2020-01-03 Diskussionsfäden David Crochet


Bonjour

Le 03/01/2020 à 17:37, Arnaud Champollion a écrit :
--> Cas numéro 1 : ce genre de chemin doit-il figurer sur la carte ? 
Au même titre que des allés situées à l'intérieur de pripriétés ? Avec 
le tag access=private ?


Si je pars du principe de « je le vois », c'est tout à fait logique que 
cela soit dans OSM, mais ce n'est pas une priorité, sauf dans la cas où 
il y a abus du public allant dans un chemin pensant que c'est publique 
alors que c'est privé. Là OSM à tous son sens pour indiquer l'accès 
interdit à tout le monde, sauf pour aller rejoindre le destinataire




--> Cas numéro 4 : du point de vue du terrain concret, ce serait 
access=private , du point de vue légal ce serait access=yes donc on 
privilégie quoi ? 


En référé au Maire et avoir sa réponse.

Cordialement

--
David Crochet


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

Re: [Talk-cl] Retos de MapRoulette en Chile

2020-01-03 Diskussionsfäden Andrew Wiseman via Talk-cl

Saludos,

Actualicé los retos con datos nuevos para Chile. Hay una pagina aquí con todos 
los retos incluyendo caminos cruzando, carreteras flotantes, vías superpuestas, 
problemas de enrutamiento y otros. También hay un reto nuevo sobre 
inconsistencias de ortografía del nombre del camino -- cuando vías conectadas 
tienen nombres similares.

https://maproulette.org/browse/projects/38976 
 

Muchas gracias,

Andrew 

Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 


> On Jul 23, 2019, at 11:49 AM, Andrew Wiseman  wrote:
> 
> Hola,
> 
> He publicado otro reto de MapRoulette, para las líneas de costa en Chile. 
> Esta reto busca partes de la costa que están muy largas o con esquinas 
> agudos, que pueden deberse a digitalización inexacta o a muy pocos vértices o 
> esquinas como sea necesario. Hay más detalles y instrucciones en el reto: 
> https://maproulette.org/challenge/8259 
> 
> 
> Por favor, hágamelo saber si tiene alguna pregunta o comentario. 
> 
> Saludos,
> 
> Andrew
> 
> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
> 
> 
>> On Jan 29, 2019, at 5:48 PM, Andrew Wiseman via Talk-cl 
>> mailto:talk-cl@openstreetmap.org>> wrote:
>> 
>> Hola OSM Chile,
>> 
>> Esto es Andrew del equipo de mapas de Apple. Llevamos algún tiempo 
>> trabajando en el red vial (https://github.com/osmlab/appledata/issues/35 
>> ) y recientemente usado 
>> nuestro herramienta Atlas para análisis de datos 
>> (https://github.com/osmlab/atlas ) para 
>> buscar algunos tipos de posibles problemas, como carreteras con ángulos 
>> agudos, intersecciones de edificios y carreteras, y lugares donde la 
>> clasificación de “highway_link” no coincide con la clasificación más alta de 
>> las carreteras. Pongo los resultados de los retos en MapRoulette 
>> (maproulette.org ), un herramienta que te permite 
>> pasar los problemas uno por uno y corregirlos o marcar que no son un 
>> problema. Quería hacerles saber que estaban disponibles en caso de que 
>> alguien quisiera intentar arreglarlos. Yo también arreglaré algunos.
>> 
>> En MapRoulette escoges un problema random o haz clic en un problema 
>> especifico. Si desea ver tareas en un lugar determinado, como en un lugar 
>> con el que está familiarizado, puede hacer clic en "más opciones" y luego en 
>> “load tasks by proximity” (cargar tareas por proximidad.)
>> 
>> Por favor, hágamelo saber si tiene alguna pregunta o comentario.
>> 
>> Los retos son:
>> 
>> Carreteras y vías de ángulo agudo: 
>> https://maproulette.org/mr3/challenge/3573 
>> 
>> Intersecciones de edificios y carreteras: 
>> https://maproulette.org/mr3/challenge/3459 
>> 
>> Carreteras de enlaces: https://maproulette.org/mr3/challenge/3574 
>> 
>>  
>> Muchas gracias,
>> 
>> Andrew
>> 
>> 
>> 
>> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
>> ___
>> 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: [OSM-talk-fr] Chemins publics / privés / ouverts / fermés

2020-01-03 Diskussionsfäden deuzeffe


Le 03/01/2020 à 17:37, Arnaud Champollion a écrit :

Bonjour,


Pareil mais soir,

Le chemin à l'ouest est sur une parcelle numérotée 148, donc a priori il 
est privé.


Le chemin à l'est n'a pas de numéro, donc a priori il est communal, et 
c'est un accaparement par le propriétaire mitoyen.


Petit bémol : les communes ont le droit d'être propriétaire de parcelles 
cadastrées avec des "chemins" qui en font partie ;)


Seul la connaissance du terrain peut trancher, amha.

--
deuzeffe - Le terrain vous dis-je, le terrain !

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

Re: [Talk-it] Negozio abbigliamento sportivo brand unico.

2020-01-03 Diskussionsfäden liste DOT girarsi AT posteo DOT eu

Il 03/01/20 16:16, scratera ha scritto:
> ...ti stimolo la curiosità
> https://gramho.com/location/montura-store-borgo-valsugana/670670603487842

Grazie, ho visto, ma per quel che era la mia domanda, ha avuto risposta
in qualche modo, ed ho taggato come outdoor, il resto non
m'incuriosisce, e non vorrei trasformare la discussione in pubblicità
gratuita.


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

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

[OSM-talk-fr] Chemins publics / privés / ouverts / fermés

2020-01-03 Diskussionsfäden Gautier Pelloux-Prayer via Talk-fr

Bonjour,

Les chemins passent parfois sur des parcelles privées (cadastrées) ou
zones communales (pas de numéro au cadastre). Il arrive que ces chemins
soient fermés au public.

On a donc, en simplifiant, quatre cas :

1) le cas du chemin situé sur parcelle privée, et d'accès privé.

2) le cas du chemin situé sur parcelle privée, mais passage autorisé
(c'est le cas concrètement de beaucoup de sentiers de randonnée)

3) le cas du chemin situé sur parcelle publique, et d'accès autorisé

4) le cas du chemin situé sur parcelle publique, mais "accaparé" par le
propriétaire mitoyen

Je me pose plusieurs questions sur la façon de bien cartographier.

--> Cas numéro 1 : ce genre de chemin doit-il figurer sur la carte ? Au
même titre que des allés situées à l'intérieur de pripriétés ? Avec le
tag access=private ?

--> Cas numéro 4 : du point de vue du terrain concret, ce serait
access=private , du point de vue légal ce serait access=yes donc on
privilégie quoi ?

Cas d'école, dont il a déjà été question il y a un peu plus d'un an :
https://lists.openstreetmap.org/pipermail/talk-fr/2018-October/090681.html

Dans le bassin dignois, il y a deux contributeurs qui ont pris
l'habitude d'utiliser l'attribut "name" pour qualifier d' "accaparé" les
chemins fermés par des propriétaires. Qu'ils soient légalement privés ou
communaux, d'ailleurs.

A priori, c'est une mauvaise utilisation de l'attribut "name". Cela a
déjà été signifié au contributeur, en lui demandant notamment ce qu'il
voulait signifier ainsi, mais les commentaires restent pour le moment
sans réponse.

Je me suis dit qu'on pourrait, pour faire propre et conserver les
informations apportés maladroitement :

- déplacer en masse tous ces attributs name=accaparé vers
description=accaparé

- qualifier correctement ces chemins avec la clé access

C'est pour cette deuxième tâche que je vous pose les questions des cas 1
et 4.

Comme il y a deux "accaparés" près de chez moi je suis allé voir
concrètement ce que c'était :

https://www.openstreetmap.org/#map=19/44.08683/6.22991

En effet, il y a un portail de chaque côté et on devine avec quelques
efforts que ça a été, à une époque, des chemins piétons. C'est désormais
envahi de broussailles, et comme c'est étroit et coincé entre des
bâtiments, si on ne sait pas on passe à côté sans les voir.

J'ai regardé ce que ça donnait au cadastre :

https://www.geoportail.gouv.fr/carte?c=6.229741167994319,44.08693104665727=19=OPEN_STREET_MAP::GEOPORTAIL:OGC:WMTS(1)=CADASTRALPARCELS.PARCELS::GEOPORTAIL:OGC:WMTS(1)=yes

Le chemin à l'ouest est sur une parcelle numérotée 148, donc a priori il
est privé.

Le chemin à l'est n'a pas de numéro, donc a priori il est communal, et
c'est un accaparement par le propriétaire mitoyen.

Du point de vue du terrain, ces chemins n'existent pas, dans le sens où
ils sont quasi-invisibles et impraticables. C'est presque un "cas numéro
5", je dirais qu'ils devraient pas être du tout sur OSM.

Qu'en pensez-vous ?

--
Arnaud Champollion

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

Re: [OSM-talk-fr] barrier=block infranchissable à vélo malgré bicycle=yes


Bonjour,

Pas de soucis particulier ici. BRouter privilégie un autre itinéraire, 
car la route au sud de la "barrière" est en sens inverse vélo, le profil 
par défaut "cyclotourisme" pénalise fortement cela.


1. Si on inverse le chemin, il prend la barriére sans soucis.

2. Si on demande à brouter d'utiliser une alternative (en haut à gauche, 
au même endroit que le choix du profil), il prend la barrière.


3. Si on utilise un autre profil (par exemple "chemin le plus court", il 
y passe aussi).


Pour info, Brouter utilise le chemin avec le plus faible coût (on peut 
le voir en bas de la page).


On peut aussi voir le détails du calcul avec la 3ème icône à droite :

Bonne journée,

Le 02/01/2020 à 18:27, Florimond Berthoux a écrit :

Pour répondre à ta question, oui c'est la bonne façon de tagguer.

Ça ne serait pas dû au bout de rue piétonne ?
(que je trouve un peu inutile ici par ailleurs)

Le jeu. 2 janv. 2020 à 12:32, Shohreh  a écrit :

Oui, c'est bizarre. Si on étend le parcours, il fait faire tout le tour
plutôt que d'aller tout droite dans cette rue calme. C'est pour ça que j'ai
pensé à cette barrière au milieu, mais ça ne semble pas être ça
l'explication.

Merci.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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



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

Re: [Talk-it] Negozio abbigliamento sportivo brand unico.

2020-01-03 Diskussionsfäden scratera

liste DOT girarsi AT posteo DOT eu wrote
> Il 31 Dicembre 2019 15:37:18 CET, scratera 

> pizpiz@

>  ha scritto:
>>..vedo zaini in vetrina 
>>https://www.montura.it/file_public/alpstation_store/102/gallery/_6.jpg
>>..e in futuro si allrgherà l'offerta da parte del buon Roberto ideatore
>>del
>>brand...
>>
>>
>>
>>--
>>Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>>
>>___
>>Talk-it mailing list
>>

> Talk-it@

>>https://lists.openstreetmap.org/listinfo/talk-it
> 
> boh, può essere vendano anche quelli, non sono mai entrato da quando
> l'hanno aperto.
> 
> --simone girardelli--
> ##
> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
> 
> ___
> Talk-it mailing list

> Talk-it@

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

...ti stimolo la curiosità
https://gramho.com/location/montura-store-borgo-valsugana/670670603487842



--
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-GB] Firmware update for older Garmin etrex devices

2020-01-03 Diskussionsfäden SK53

I don't think so, because it recorded tracks with the right dates in
November, so apparently somewhere between 20th November last year and 1st
Jan this year.

Jerry

On Fri, 3 Jan 2020 at 14:05, Gareth L  wrote:

> A victim of the gps week roll over in April last year maybe? If so, you
> should be good until November 2038 (although there’s plenty of other epochs
> that will break stuff before then I reckon)
> Gareth
>
> On 3 Jan 2020, at 13:38, SK53  wrote:
>
> 
> I was using an older Garmin etrex Legend HC as a backup track recorder
> over the New Year, and failed to find my tracks. It turns out that the date
> is incorrect and instead of 1st Jan 2020 the device was registering 17 May
> 2000.
>
> Anyone who still uses these may be interested that a firmware patch is
> available: (https://support.garmin.com/en-GB/?faq=qpVUfZBKI28PqnPd6HuXa6.
>
> I've run this from Windows 10 successfully for my GPS.
>
> Happy New Year,
>
> Jerry
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir

2020-01-03 Diskussionsfäden Jérôme Amagat

J'ajoute que je ne suis pas contre le fait de ce servir de ces lieu dit du
cadastre pour ajouter des place=* ou d'autre chose dans osm, je le fait
régulièrement mais j'aimerai qu'il y ai un peu de réflexion avant
d'importer, si le nom contient château vérifié que ce n'est pas le nom d'un
château présent pas loin, pareil pour un moulin, un bois... vérifier si
c'est le nom d'un groupe d'habitation ou des terrain à coté...

Pareil pour fantoir, c'est pas parce que c'est présent dans cette base de
donnée que ça a obligatoirement sa place dans osm, il y a pas mal d'erreur
présentes ou des chose qui n'existe plus

Le ven. 3 janv. 2020 à 15:06, Jérôme Amagat  a
écrit :

>
>
>> Mais pas systématiquement. "Le moulin de" fait parti de l'adresse de ma
>> cousine par exemple. Ça correspond à un vrai usage, donc ça a sa place dans
>> osm, non ?
>>
>> C'est pour ça que j'ai écrit : "quand le château existe encore et que le
> terme désigne seulement ce château". pareil pour les moulins.
>
> Sinon, 820  place=* name="Le Bourg" ou "Au Bourg" ou "Bourg" (il y en en
> sûrement quelques uns de légitime mais pas la plupart)
> https://overpass-turbo.eu/s/Pqj
> dont plus de la moitié place=locality
> Pour un bon nombre même pas sur le bourg mais un peu a coté là ou c'est
> écrit sur le cadastre
>
> Pour Château, plus de 650 (dont une cinquantaine sans accent circonflexe)
> et je n’inclus pas les "Château machin". Dans ce cas c'est plus compliqué
> que le bourg je suis d'accord ,pour beaucoup le nom fait référence a un
> hameau ou a un bâtiment qui n'est pas un château mais est ce qui s'en
> approche le plus sur la commune...
>
> Je comprend pas bien les avis, il doit y avoir près d'une discussion sur 2
> ou il y a au moins quelqu"un qui va dire "c'est le terrain qui prime ..."
> mais là parce que c'est soit disant ancien on se fout de savoir si c'est
> encore utilisé ou même si ça a été un jour été utilisé ailleurs que sur le
> cadastre.
> Et donc il y plein de communes ou les lieux dit du cadastre on été importé
> directement sans vérification, tous ou presque avec place=locality, placé
> là où c'est écrit sur le cadastre même si on est très loin du lieu réel.
> Toujours sur le cadastre, mais là il n'y a pas ce rapport à "l'ancien", il
> est pas conseillé d'importer les adresses sans vérification. Pour les
> rivières pressentent sur le cadastre il y avait des restrictions à son
> import dans osm.
> Dans un cas le cadastre à tout bon, dans d'autres c'est approximatif et il
> faut vérifier.
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir

2020-01-03 Diskussionsfäden Vincent de Château-Thierry

Ben quand on se retrouve avec des champs ou une route avec un nom de
lieu-dit que je ne
connaissais pas malgré ma connaissance du terrain :
https://www.openstreetmap.org/#map=19/48.15750/-1.69837

Julien “djakk”


Le ven. 3 janv. 2020 à 15:07, Jérôme Amagat  a
écrit :

>
>
>> Mais pas systématiquement. "Le moulin de" fait parti de l'adresse de ma
>> cousine par exemple. Ça correspond à un vrai usage, donc ça a sa place dans
>> osm, non ?
>>
>> C'est pour ça que j'ai écrit : "quand le château existe encore et que le
> terme désigne seulement ce château". pareil pour les moulins.
>
> Sinon, 820  place=* name="Le Bourg" ou "Au Bourg" ou "Bourg" (il y en en
> sûrement quelques uns de légitime mais pas la plupart)
> https://overpass-turbo.eu/s/Pqj
> dont plus de la moitié place=locality
> Pour un bon nombre même pas sur le bourg mais un peu a coté là ou c'est
> écrit sur le cadastre
>
> Pour Château, plus de 650 (dont une cinquantaine sans accent circonflexe)
> et je n’inclus pas les "Château machin". Dans ce cas c'est plus compliqué
> que le bourg je suis d'accord ,pour beaucoup le nom fait référence a un
> hameau ou a un bâtiment qui n'est pas un château mais est ce qui s'en
> approche le plus sur la commune...
>
> Je comprend pas bien les avis, il doit y avoir près d'une discussion sur 2
> ou il y a au moins quelqu"un qui va dire "c'est le terrain qui prime ..."
> mais là parce que c'est soit disant ancien on se fout de savoir si c'est
> encore utilisé ou même si ça a été un jour été utilisé ailleurs que sur le
> cadastre.
> Et donc il y plein de communes ou les lieux dit du cadastre on été importé
> directement sans vérification, tous ou presque avec place=locality, placé
> là où c'est écrit sur le cadastre même si on est très loin du lieu réel.
> Toujours sur le cadastre, mais là il n'y a pas ce rapport à "l'ancien", il
> est pas conseillé d'importer les adresses sans vérification. Pour les
> rivières pressentent sur le cadastre il y avait des restrictions à son
> import dans osm.
> Dans un cas le cadastre à tout bon, dans d'autres c'est approximatif et il
> faut vérifier.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir

2020-01-03 Diskussionsfäden Jérôme Amagat

>
> Mais pas systématiquement. "Le moulin de" fait parti de l'adresse de ma
> cousine par exemple. Ça correspond à un vrai usage, donc ça a sa place dans
> osm, non ?
>
> C'est pour ça que j'ai écrit : "quand le château existe encore et que le
terme désigne seulement ce château". pareil pour les moulins.

Sinon, 820  place=* name="Le Bourg" ou "Au Bourg" ou "Bourg" (il y en en
sûrement quelques uns de légitime mais pas la plupart)
https://overpass-turbo.eu/s/Pqj
dont plus de la moitié place=locality
Pour un bon nombre même pas sur le bourg mais un peu a coté là ou c'est
écrit sur le cadastre

Pour Château, plus de 650 (dont une cinquantaine sans accent circonflexe)
et je n’inclus pas les "Château machin". Dans ce cas c'est plus compliqué
que le bourg je suis d'accord ,pour beaucoup le nom fait référence a un
hameau ou a un bâtiment qui n'est pas un château mais est ce qui s'en
approche le plus sur la commune...

Je comprend pas bien les avis, il doit y avoir près d'une discussion sur 2
ou il y a au moins quelqu"un qui va dire "c'est le terrain qui prime ..."
mais là parce que c'est soit disant ancien on se fout de savoir si c'est
encore utilisé ou même si ça a été un jour été utilisé ailleurs que sur le
cadastre.
Et donc il y plein de communes ou les lieux dit du cadastre on été importé
directement sans vérification, tous ou presque avec place=locality, placé
là où c'est écrit sur le cadastre même si on est très loin du lieu réel.
Toujours sur le cadastre, mais là il n'y a pas ce rapport à "l'ancien", il
est pas conseillé d'importer les adresses sans vérification. Pour les
rivières pressentent sur le cadastre il y avait des restrictions à son
import dans osm.
Dans un cas le cadastre à tout bon, dans d'autres c'est approximatif et il
faut vérifier.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Firmware update for older Garmin etrex devices

2020-01-03 Diskussionsfäden Gareth L

A victim of the gps week roll over in April last year maybe? If so, you should 
be good until November 2038 (although there’s plenty of other epochs that will 
break stuff before then I reckon)
Gareth

On 3 Jan 2020, at 13:38, SK53  wrote:


I was using an older Garmin etrex Legend HC as a backup track recorder over the 
New Year, and failed to find my tracks. It turns out that the date is incorrect 
and instead of 1st Jan 2020 the device was registering 17 May 2000.

Anyone who still uses these may be interested that a firmware patch is 
available: (https://support.garmin.com/en-GB/?faq=qpVUfZBKI28PqnPd6HuXa6.

I've run this from Windows 10 successfully for my GPS.

Happy New Year,

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

Re: [OSM-talk-fr] Adresse renseigné en import de masse...

Bonjour,

> De: "Jérôme Seigneuret" 
> À: "Vincent de Château-Thierry" , "Discussions sur OSM en 
> français" 
> 
> Je pense que le sujet est récurent mais il serait intéressant dans
> tes outils de @Vincent sur la partie Fantoir de voir si les numéros
> renseignés sur une rue dans OSM existe ou non dans les autres
> référentiels et pas seulement sur les fonds de plans disponibles.
> 
(...)
> 
> Peut-on adapté le travail que tu as fait au niveau des rue avec un
> tableau des numéros existants ou non dans chaque référentiel afin de
> voir ce qui peuvent être problématique?
> 
> 
> voie osm | fantoir | IGN | la poste | données commune | autre peut
> importe que la voie soit rapprochée ou non
> 
> | addr:number | oui | non | oui| non | non | - < dans le cas présent
> | pas de donnée impôt et postal on peut donc ce dire que le numéro
> | n'a plus lieu d'être. (ou date ou version de la derrière entrée
> | connue ça peut être en poup pour les infos complémentaire sur les
> | casses à "oui")
> 
> 
> Ca va offrir deux choses: l'ajout des nouveaux numéros sera visible
> donc la maintenance sera plus simple pour ce qui ont déjà intégré
> toute leur ville
> On pourra virer ou mettre en disued:addr:housenumber les numéros qui
> n' ont plus d’existence terrain (cas d'accès sur une autre rue avec
> déplacement du portail) rue coupée en deux et renommage partiel de
> la voirie sur le prolongement de la rue adjacente... Bref plein de
> cas de terrain.

On peut "descendre" au numéro pour avoir un panorama des numéros en fonction 
des sources, et proposer leur intégration (comme c'est déjà partiellement le 
cas sur http://dev.cadastre.openstreetmap.fr/fantoir/ pour les voies avec 
adresses) numéro par numéro plutôt que rue par rue. Je pense que l'intérêt sera 
moins dans la possibilité d'intégration que dans celle de qualifier un numéro, 
par exemple pour statuer sur son état fictif (les n° en 5000 ou 9000 du 
cadastre) ou son caractère obsolète. Ca pourrait se faire avec un peu la même 
ergonomie que pour caractériser les voies, avec une liste de statuts, qu'on 
affinera au fil des trouvailles et bizarreries.
Je dis "descendre" au numéro car il faut juste être conscients qu'on s'attaque 
là à un paquet de plus de 20 millions de points, plus ou moins multipliés par 
le nombre de sources en un même endroit. Ca fait du monde, du temps, du clic, 
bien plus que pour la gestion des rues. Mais pourquoi pas, on verra à l'usage 
si ça permet une mise en qualité. Ca colle en tout cas avec l'objectif de 
garder OSM comme source prioritaire dans BANO : plus on saura qualifier les 
sources d'adresses, mieux on saura dans quelles sources piocher au cas par cas 
pour enrichir OSM.

À suivre ici : https://github.com/osm-fr/osm-vs-fantoir/issues/74

vincent

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

[Talk-GB] Firmware update for older Garmin etrex devices

2020-01-03 Diskussionsfäden SK53

I was using an older Garmin etrex Legend HC as a backup track recorder over
the New Year, and failed to find my tracks. It turns out that the date is
incorrect and instead of 1st Jan 2020 the device was registering 17 May
2000.

Anyone who still uses these may be interested that a firmware patch is
available: (https://support.garmin.com/en-GB/?faq=qpVUfZBKI28PqnPd6HuXa6.

I've run this from Windows 10 successfully for my GPS.

Happy New Year,

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

Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir

2020-01-03 Diskussionsfäden Christian Quest

A part les est/ouest/nord/sud qui sont uniquement administratifs, le reste
pour moi n'a pas à être séparé.

Certes, ce ne sont pas des noms très souvent utilisés, mais utilisés, en
quoi cela devrait les mettre à un second rang et sur quelle base objective
faire le tri ?

On a déjà un tri qui se fait sur le place=* associé... qui indique quelque
part son importance, si c'est un lieu habité ou pas par exemple.

Quand un lieu porte un nom, qui n'est peut être pas affiché sur le terrain,
mais qui n'a pas été remplacé par un autre (sinon il passerait en
old_name), qui même si il n'est pas utilisé par grand monde reste son nom
actuel, le seul tag qui semble correct est name=*

C'est quoi le problème ? En quoi ça gêne ?


Le ven. 3 janv. 2020 à 14:16, Julien djakk  a
écrit :

> Cyrille, en tout cas j’aimerai trouver un moyen de distinguer ces
> lieux-dits uniquement administratifs, des autres, encore utilisés ;)
>
> Julien “djakk”
>
> Le ven. 3 janv. 2020 à 13:54, Donat ROBAUX  a écrit :
>
>> Ce n'est techniquement pas un ancien nom vs nouveau nom. C'est un nom
>> ancien
>> qui n'est plus utilisé ou si peu, donc tombé en désuétude. On crée un
>> disused:name ?
>>
>> Donat
>>
>
-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir

Cyrille, en tout cas j’aimerai trouver un moyen de distinguer ces
lieux-dits uniquement administratifs, des autres, encore utilisés ;)

Julien “djakk”



Le ven. 3 janv. 2020 à 13:54, Donat ROBAUX  a écrit :

> Ce n'est techniquement pas un ancien nom vs nouveau nom. C'est un nom
> ancien
> qui n'est plus utilisé ou si peu, donc tombé en désuétude. On crée un
> disused:name ?
>
> Donat
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Casemate

2020-01-03 Diskussionsfäden Yves P.


>> utiliser location=underground pour tout l’objet si il est effectivement 
>> enterré, et sinon, mettre cet attribut uniquement sur les segments qui le 
>> sont.
> Effectivement, je viens de faire l'essai, le bâtiment n'est plus représenté 
> du tout, ça ne peut donc pas marcher comme ça…
> 
> […]
>  À moins de faire une relation, et que ce soit la relation qui porte le « 
> building »   ?
> 
Oui essai à tout hasard. Dans le meilleur des cas le bâtiment va être rendu 
comme avant, dans le pire il va « disparaitre ».

>> Il faudrait affiner la requête en cherchant les chemins avec 2 noeuds ou des 
>> chemins non fermés.
> Cf. plus haut.
C’était pour voir si quelqu’un avait essayé (il y a beaucoup d’attributs dans 
la base qui ne sont pas rendu par les moteurs de base, et affichés dans des 
applications spécialisées ou utilisés dans des requêtes overpass…)

>> Avec cette illustration : 
>> http://hammerbud.pl/wp-content/uploads/2013/06/Ruciana_front-900x564.jpg 
>> Sauf
>>  que dans cet exemple, il n'y a rien d'enterré, sauf des « façades », alors 
>> que dans mon problème, tout est enterré, sauf la façade.
> 
Oui, mais on retrouve un problème aussi commun des bâtiments dans une pente 
avec 2 ou plusieurs étages de plein pieds, ou un R.d.C en « haut ».
Ils ont souvent une partie (semi) enterrée.
> La question reste ouverte, et je pense qu'on ne s'en sortira pas comme ça. Je 
> veux dire sans demander des solutions à la communauté, qui passeront il 
> semblerait bien par la définition de nouveaux objets, ou du moins 
> l'acceptation de bâtiments composés de chemins différents, et pas un unique 
> chemin.
> 
Je effectivement à discuter d’une « solution » sur cette liste, de la tester 
éventuellement avec « nos »  spécialistes du rendu, et enfin d’ouvrir cette 
discussion sur les listes internationales.

> Et comme je ne parle ni n'écris et comprends pas tellement plus l'anglais…
> 
Je parle anglais, mais je n’ai aucune expérience de ces listes…

Heureusement, il y a des spécialistes sur cette liste.

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

Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir

2020-01-03 Diskussionsfäden Donat ROBAUX

Ce n'est techniquement pas un ancien nom vs nouveau nom. C'est un nom ancien
qui n'est plus utilisé ou si peu, donc tombé en désuétude. On crée un
disused:name ? 

Donat




--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir

2020-01-03 Diskussionsfäden Cyrille37 OSM


Le 03/01/2020 à 12:51, Julien djakk a écrit :
Christian, ok pour ton point de vue. Si c’est toujours utilisé dans le 
notariat, mais plus utilisé par ailleurs, est-ce qu’on ne taggerait 
pas avec old_name uniquement ?


Mais comment savoir s'il ne sont pas utilisés par ailleurs ... Il y a 
tellement d'autres améliorations à faire dans OSM qu'on pourrait laisser 
ces bons vieux lieux-dits tranquille ;-)


Cyrille37.



Julien “djakk”


Le ven. 3 janv. 2020 à 12:41, deuzeffe > a écrit :


Le 03/01/2020 à 12:35, Christian Quest a écrit :

> Il n'y a que l'ajout des points cardinaux par la DGFiP qui est
> artificiel et ne correspond qu'à une vue isolée d'une
administration.

This is my point. Thx.
-- 
deuzeffe


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


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

Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir

Christian, ok pour ton point de vue. Si c’est toujours utilisé dans le
notariat, mais plus utilisé par ailleurs, est-ce qu’on ne taggerait pas
avec old_name uniquement ?

Julien “djakk”


Le ven. 3 janv. 2020 à 12:41, deuzeffe  a écrit :

> Le 03/01/2020 à 12:35, Christian Quest a écrit :
>
> > Il n'y a que l'ajout des points cardinaux par la DGFiP qui est
> > artificiel et ne correspond qu'à une vue isolée d'une administration.
>
> This is my point. Thx.
> --
> deuzeffe
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir

2020-01-03 Diskussionsfäden deuzeffe


Le 03/01/2020 à 12:35, Christian Quest a écrit :

Il n'y a que l'ajout des points cardinaux par la DGFiP qui est 
artificiel et ne correspond qu'à une vue isolée d'une administration.


This is my point. Thx.
--
deuzeffe

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

Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir

2020-01-03 Diskussionsfäden Christian Quest

Le ven. 3 janv. 2020 à 09:57, Cyrille37 OSM  a
écrit :

> Hello
>
> Ces lieux dits ont souvent du sens, OSM n'est pas "que" pour l'adressage
> du présent pour du routage sur smartphone. Ne pas systématiquement
> effacer les lieux-dits, s'il vous plaît.
>
> Par exemple, grâce à OSM on peut retrouver des lieux-dits cités dans des
> livres, ou par grand-mère ;-)
>
> Cyrille37.
>
>
Oh que oui !
C'est même ça qui m'a fait initialement découvrir OSM lors de mes
recherches généalogiques !

On y fait référence encore aujourd'hui dans certaines démarches, comme les
actes notariés et si vous me donnez rdv "aux sablons" dans mon bled adoptif
de l'Yonne, je sais où c'est.

Il n'y a que l'ajout des points cardinaux par la DGFiP qui est artificiel
et ne correspond qu'à une vue isolée d'une administration.

Le reste me semble utile car c'est une toponymie riche même si l'usage
n'est pas quotidien. OSM est de plus un exemple pour la toponymie avec nos:
name, alt_name, official_name, local_name, old_name... et leurs variantes
linguistiques.

Comme toujours si cela n'est pas votre tasse de thé, n'empêchez pas les
autres de contribuer dans ce domaine.

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

Re: [OSM-talk-be] Mappen van paalcampings

2020-01-03 Diskussionsfäden Gerard Vanderveken

I think it is mapped OK and in line with the examples [1] in
Meerdaalwoud. 

It exists, so it has its place on the map. 

Greetz, 

Gerard

Karel Adams schreef op 2019-12-29 15:37:

> Na enige aarzeling heb ik, proberenderwijs, de paalcamping Arkadia in Muizen 
> toegevoegd. Zie 
> https://www.openstreetmap.org/node/7093111580#map=19/51.00354/4.54221
> 
> Het zou me helemaal niet verbazen als de initiaftiefnemers daarmee 
> allesbehalve gelukikig waren, ik heb dan ook geschreven om een en ander toe 
> te lichten, en om goedkeuring te vragen. Want dit soort initiatieven houdt 
> graag een laag profiel, het allerlaatste dat men daar wil is dat er iemand 
> met een 4x4-superdeluxekampeerbus komt binnengetuft. En dat houd ik best voor 
> mogelijk, allicht zal er wel iemand campinggidsen opmaken op basis van 
> overpassqueries.
> 
> Misschien toch beter maar terug verwijderen? Of welke tags zouden er kunnen 
> toegevoegd worden om het eigen karakter van zo'n paalcamping duidelijk over 
> te brengen? Iets van "access=???" of "regulations=strict"?
> 
> Over het concept van paalcampings kan men meer lezen op o.a. 
> http://www.bivakzone.be/
> 
> Karel
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
 

Links:
--
[1] https://www.openstreetmap.org/way/222137187___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [talk-au] Did the Earth just move for you? RE WGS84

2020-01-03 Diskussionsfäden Dion Moult

My impression was that the 1.8m jump was to do with the GDA standard (and
therefore the MGA standards too). These seem like Australian specific coordinate
systems that are being adjusted. I assumed that OSM stored its data in WGS84,
which to my understanding is separate to a new definition of a GDA standard.

However, my understanding on this topic is very poor, so if others can help
explain the implications this has on OSM, if any, I'd really appreciate it :)

On Fri, Jan 03, 2020 at 09:24:21PM +1100, Warin wrote:
> 
> On 03/01/20 18:43, Dion Moult wrote:
> > How does this get solved?
> >
> > Can someone help explain to me how this affects the map? My limited
> > understanding is that this is the change from gda94 to gda2020.
> > However, does osm store things in wgs84? And that hasn't changed, has it?
> 
> For WGS84 to Australian relevance read
> https://www.ga.gov.au/scientific-topics/positioning-navigation/wgs84
> 
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

-- 
Dion Moult


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

Re: [Talk-se] Hjälp med vandringslederna

2020-01-03 Diskussionsfäden Christoffer Holmstedt

Jag har sprungit längs med Nasaleden [1] tidigare år och laddat upp GPS
spår samt försökt fylla i så mycket som möjligt av de sträckningar som
finns där.
https://hiking.waymarkedtrails.org/#route?id=8254540=10!65.2452!19.5998

Jag har inte uppdaterat wikisidan men kanske hinns med under våren.

[1] http://www.nasaleden.com/

Den fre 3 jan. 2020 kl 10:44 skrev Christian Asker <
christian.as...@gmail.com>:

> Hej. Jag fick den här PDFen från Pilgrimscentrum för sträckningen av
> Klosterleden. Bakgrundskartan är Lantmäteriet och det är ju inte en fil
> som lämpar sig för import i JOSM eller så, men man kan kika på kartorna
> och sedan lägga till objekt till rätt relation i JOSM.
>
>
> Mvh Christian
>
>
> Den 2020-01-01 kl. 12:51, skrev pangoSE:
> > Hej :)
> >
> > Jag har under det senaste år fokuserad på leder i SE och få bra
> > ordning och etapper på alla som finns beskrivna.
> >
> > Dem gånger jag frågat (tex om Världsarvsleden) har jag fått ok att
> > rita efter externa kartor.
> >
> > Läget är halvbra i dagsläget eftersom många leder fortfarande är
> > inkompletta i databasen. Vi har jättemånga långa fina leder :)
> >
> > Jag efterfrågar därför flera händer till arbetet.
> >
> > Exempel på jobb att göra är:
> >
> > * St. Olavsleden - etappindelning (5 st), övergripande relation
> > * Birgittaleden - Kontakta Emanuel Eriksson och fråga om tillstånd att
> > använda deras gpx till att rita efter
> > (
> https://www.pilgrimscentrum.se/pilgrimsvandring/v%C3%A5ra-pilgrimsleder/digitala-pilgrimsguider-26294493)
>
> >
> > * Rankåsleden - Föräldrarelation saknas...
> > * Värmdöleden - behöver ritas klart - fråga om tillstånd att rita från
> > deras kartor på hemsidan
> > * Östra Sigfridsleden - allt saknas, data finns på hemsidan, fråga om
> > tillstånd
> > * uppdatera informationen på
> > https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/Hiking_trails
> > om hur kompletta lederna är i dagsläget och vad som saknas.
> > *...
> >
> > Heja!
> >
> > Mvh
> > pangoSE
> >
> > ___
> > Talk-se mailing list
> > Talk-se@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-se
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>


-- 
Christoffer Holmstedt
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [talk-au] Did the Earth just move for you? RE WGS84


On 03/01/20 18:43, Dion Moult wrote:

How does this get solved?

Can someone help explain to me how this affects the map? My limited 
understanding is that this is the change from gda94 to gda2020. 
However, does osm store things in wgs84? And that hasn't changed, has it?


For WGS84 to Australian relevance read
https://www.ga.gov.au/scientific-topics/positioning-navigation/wgs84

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

Re: [talk-cz] [začátečníci] wikipedie k place=*

2020-01-03 Diskussionsfäden Petr Tesařík

Ahoj,

Dne Fri, 3 Jan 2020 10:41:38 +0100
Jan Macura  napsal(a):

> Ahoj
> 
> On Fri, 3 Jan 2020 at 10:23, Petr Tesařík  wrote:
> 
> > Domnívám se, že v tomto případě jsou atributy wikipedia a wikidata
> > přiřazeny chybně a měly by být spíš u příslušné podoblasti:
> > - https://www.openstreetmap.org/relation/435758
> >  
> 
> Tak, jak je to propojeno nyní, je to správně.
> https://www.openstreetmap.org/relation/438752 ->
> https://www.wikidata.org/wiki/Q2702822
> obojí popisuje město Jistebnice jako administrativní jednotku (obec).
> Jistebnice jakožto samostatné sídlo by mělo být propojeno s položkou, která
> se týká jen tohoto sídla:
> https://www.openstreetmap.org/relation/435758 ->
> https://www.wikidata.org/wiki/Q56414547

Aha. Děkuji za vysvětlení.

> Zda uvádět tagy wikidata a wikipedia (jen) do relací, (jen) do uzlů nebo do
> relací i do uzlů, nemám jasný názor,

Vzhledem k tomu, že relace dokážou pokrýt více datových položek, ke
kterým neexistuje odpovídající uzel (např. kraj či okres), přikláním se
spíš k variantě přidávat wikidata jen k relacím. Jestliže (zatím?)
turistické aplikace neumějí z relací tato data získat, mohli bychom je
kopírovat do uzlů skriptem.

Petr T

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

Re: [talk-au] Did the Earth just move for you?


On 03/01/20 18:43, Dion Moult wrote:

How does this get solved?

Can someone help explain to me how this affects the map? My limited 
understanding is that this is the change from gda94 to gda2020. 
However, does osm store things in wgs84? And that hasn't changed, has it?


wgs84 does change. It started in 1984? .. but has been modified since 
then a number of times.


The change is ~ 1.8 meters so most people are unlikely to know as 
general GPS accuracy is greater than the 1.8 metres.


Another link 
https://www.theage.com.au/national/nsw-and-victoria-just-jumped-1-8-metres-north-20200102-p53ocx.html


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

Re: [OSM-talk-fr] Casemate

2020-01-03 Diskussionsfäden Muselaar



Le 02/01/2020 à 15:06, Yves P. a écrit :

il y a peut-être plus simple :

utiliser location=underground pour tout l’objet si il est 
effectivement enterré, et sinon, mettre cet attribut uniquement sur 
les segments qui le sont.


Et on peut toujours couper le bâtiment avec une partie 
building=troglodyte et l'autre sans

C’est peut-être ce que tu veux dire ici ?

Mais pour moi, ce ne sont pas 2 polygones fermés, mais un seul avec 
avec des segments « underground ».

Sur le rendu, ils seraient représentés en pointillés.



J'ai fait comme ça, finalement, je n'aurais pas eu l'idée de couper un 
bâtiment en deux, et, du reste, JOSM m'en fait le reproche, en 
considérant que ce sont deux bâtiments non-fermés, et non un seul. Du 
coup, est-ce que ça ne risque pas de poser des problèmes 
d'interprétation par les divers moteurs de rendu, voire de prise en compte ?


Effectivement, je viens de faire l'essai, le bâtiment n'est plus 
représenté du tout, ça ne peut donc pas marcher comme ça…



J’ai fait une requête  pour essayer 
d’en trouver avec *way[building]["location"="underground"];*

ça renvoi 2302 polygones et seulement 4 chemins.

Il faudrait affiner la requête en cherchant les chemins avec 2 noeuds 
ou des chemins non fermés.

Cf. plus haut.


Je n’ai pas trouvé de discussion sur location=underground, mais une 
discussion sur les bâtiments construits dans une pente :

https://wiki.openstreetmap.org/wiki/Talk:Key:location#location.3Dsurface_with_level.3E0

Avec cette illustration : 
http://hammerbud.pl/wp-content/uploads/2013/06/Ruciana_front-900x564.jpg


Sauf que dans cet exemple, il n'y a rien d'enterré, sauf des « façades 
», alors que dans mon problème, tout est enterré, sauf la façade.


La question reste ouverte, et je pense qu'on ne s'en sortira pas comme 
ça. Je veux dire sans demander des solutions à la communauté, qui 
passeront il semblerait bien par la définition de nouveaux objets, ou du 
moins l'acceptation de bâtiments composés de chemins différents, et pas 
un unique chemin. À moins de faire une relation, et que ce soit la 
relation qui porte le « building » ?


Et comme je ne parle ni n'écris et comprends pas tellement plus l'anglais…

Muselaar

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

Re: [talk-cz] [začátečníci] wikipedie k place=*

2020-01-03 Diskussionsfäden Jan Macura

Mimochodem,

těm z vás, kteří by se tomuto propojování chtěli věnovat, a zároveň chtěli
mít kontrolu, že to dělají dobře, doporučuji založit si účet Wikimedia a do
uživatelského JavaScriptu na Wikidatech (např.
https://www.wikidata.org/wiki/User:YjM/common.js ) si přidat následující
řádek:

mw.loader.load(
'//www.wikidata.org/w/index.php?title=User:Mxn/overpass.js=raw=text/javascript'
); // [[User:Mxn/overpass.js]]

U každé položky na Wikidatech pak uvidíte mapku s relací v OSM, která je s
danou položkou propojená.

H.

On Fri, 3 Jan 2020 at 10:41, Jan Macura  wrote:

> Ahoj
>
> On Fri, 3 Jan 2020 at 10:23, Petr Tesařík  wrote:
>
>> Domnívám se, že v tomto případě jsou atributy wikipedia a wikidata
>> přiřazeny chybně a měly by být spíš u příslušné podoblasti:
>> - https://www.openstreetmap.org/relation/435758
>>
>
> Tak, jak je to propojeno nyní, je to správně.
> https://www.openstreetmap.org/relation/438752 ->
> https://www.wikidata.org/wiki/Q2702822
> obojí popisuje město Jistebnice jako administrativní jednotku (obec).
> Jistebnice jakožto samostatné sídlo by mělo být propojeno s položkou,
> která se týká jen tohoto sídla:
> https://www.openstreetmap.org/relation/435758 ->
> https://www.wikidata.org/wiki/Q56414547
>
> Zda uvádět tagy wikidata a wikipedia (jen) do relací, (jen) do uzlů nebo
> do relací i do uzlů, nemám jasný názor,
>
> H.
>
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] [začátečníci] wikipedie k place=*

2020-01-03 Diskussionsfäden Jan Macura

Ahoj

On Fri, 3 Jan 2020 at 10:23, Petr Tesařík  wrote:

> Domnívám se, že v tomto případě jsou atributy wikipedia a wikidata
> přiřazeny chybně a měly by být spíš u příslušné podoblasti:
> - https://www.openstreetmap.org/relation/435758
>

Tak, jak je to propojeno nyní, je to správně.
https://www.openstreetmap.org/relation/438752 ->
https://www.wikidata.org/wiki/Q2702822
obojí popisuje město Jistebnice jako administrativní jednotku (obec).
Jistebnice jakožto samostatné sídlo by mělo být propojeno s položkou, která
se týká jen tohoto sídla:
https://www.openstreetmap.org/relation/435758 ->
https://www.wikidata.org/wiki/Q56414547

Zda uvádět tagy wikidata a wikipedia (jen) do relací, (jen) do uzlů nebo do
relací i do uzlů, nemám jasný názor,

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

Re: [OSM-talk-fr] Blocage de oc-OpenStreetMap [était Re: pb sur un cset lié aux langues locales]

2020-01-03 Diskussionsfäden Vincent Bergeot


Re,
le blocage n'a pas été demandé encore, il manquait un point 
d'interrogation mais au vu des divers retours, je lance la demande !


à plus



Le 03/01/2020 à 10:04, Vincent Bergeot a écrit :

Bonjour,

je suis également étonné par les tailles de changesets de cet 
utilisateur 
(https://www.openstreetmap.org/user/oc-OpenStreetMap/history#map=6/45.506/1.861).


Cela me pose plusieurs questions :

- peu d'informations sur les commentaires de changesets, toujours 
pareil : name:oc localization
- pas d'informations sur le compte : 
https://www.openstreetmap.org/user/oc-OpenStreetMap : l'utilisation 
d'openstreetmap dans le nom, laissant penser à un compte "officiel"
- de plus les changesets sont tous conséquents 'entre 8000 et 1 
objets modifiés", avec des intervalles courtes entre, ...
- et sans avoir vérifié mais dans beaucoup de cas c'est "juste" de 
l'ajout d'une source ieo-bdtopoc comme ici 
https://www.openstreetmap.org/way/743094652/history

- le rythme est très soutenu (trop soutenu je pense)


J'ai fait un commentaire ici : 
https://www.openstreetmap.org/changeset/79146537#map=8/44.099/5.845


à bloquer je pense




Le 02/01/2020 à 16:34, Landry Breuil a écrit :

Hello,

pas fait d'OSM depuis un bail, mais en me promenant dans un coin que je
connais bien (lieu dit nommé 'le pous' ou 'lou pous' sur les panneaux
sur place), dans osmand (et sur la carte d'osm.org) j'ai eu la surprise
de voir 'Le Potz' qui est un nom completement inconnu sur place. - le
nom était correct pour moi auparavant (cf
https://www.openstreetmap.org/node/2077266629/history il y'a 8 mois), et
a été modifié par oc-OpenStreetMap dans le changeset
https://www.openstreetmap.org/changeset/70878777 .

Pour moi ce changement est incorrect pour les tags name et name:fr qui
devraient a minima être name:fr='Le Pous' et/ou name='Lou Pous', et
après etre rentré en contact avec l'utilisateur (qui est clairement un
défenseur de la langue occitane?) via la messagerie du site, je n'arrive
pas a un consensus. Je ne vais pas rapporter ici nos échanges qui sont a
mon avis rapidement peu constructifs.

Dans OSM le terrain a toujours primé, les panneaux du lieu dit utilisent
'Lou Pous', les panneaux indicateurs de rando 'Le Pous', nulle part je
n'ai vu 'Le Potz'. Peu importe l'étymologie, la linguistique et la
défense des langues locales, selon moi la base est maintenant fausse.

Est-ce que qqn peut m'éclairer sur ce point ?

merci!

Landry

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





--
Vincent Bergeot


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

Re: [talk-cz] [začátečníci] wikipedie k place=*

2020-01-03 Diskussionsfäden Petr Tesařík

Ahoj,

já jsem si zase všiml, že kromě [place=village] se to týká také
[place=town]. Ovšem, jako obvykle, celá věc je poněkud složitější.
Vezmu jako příklad své bydliště.

Uzel města [place=town]:
- https://www.openstreetmap.org/node/1599258376
- nemá atributy wikipedia a wikidata

Město je součástí relace Jistebnice:
- https://www.openstreetmap.org/relation/438752
- má atributy wikipedia a wikidata

Hranice této relace ale zahrnují i všechny osady, které spadají pod MěÚ
Jistebnice (Božejovice, Padařov, Makov, Vlásenice, atd.), z nichž mnohé
mají vlastní datovou položku ve Wikidata a vlastní stránku na Wikipedii.

Domnívám se, že v tomto případě jsou atributy wikipedia a wikidata
přiřazeny chybně a měly by být spíš u příslušné podoblasti:
- https://www.openstreetmap.org/relation/435758

Otázkou zůstává, zda se mají duplikovat i u příslušného uzlu města,
nebo ne, případně jestli se mají naopak u té relace smazat.

Každopádně by bylo dost obtížné takovéto případy upravit automaticky,
aniž by vznikl ještě větší zmatek.

Petr T


Dne Thu, 02 Jan 2020 17:05:57 +0100 (CET)
"Radek Svoboda"  napsal(a):

> Ahoj,
> 
> 
> 
> 
> letmo jsem se koukal, jaké mají nody okolních obcí "pokrytí" s linky na wiki
> a je fakt, že je to celkem slabé. Narazil jsem ale na poměrně dost bodů 
> [place=village], které jsou součástí relace [type=boundary][boundary=
> administrative], která již odkaz na wiki a wikidata má.
> 
> 
> 
> 
> 
> Např. 
> 
> Node: Šanov (1601754741)  https://www.openstreetmap.org/node/1601754741
> 
> Relation: Šanov (438717) https://www.openstreetmap.org/relation/438717
> 
> 
> i ten odkazovaný Domašov ;-)
> 
> 
> 
> 
> Předpokládám, že turistické aplikace moc nečtou data z relací, a je tedy 
> potřeba mít data duplicitně. Ale i tak, nešlo by to nějak automatizovaně 
> překopírovat/porovnávat. 
> 
> Je mi proti srsti doplňovat něco ručně (nebo k tomu někoho nabádat :-) ), 
> když už ta data už v db jsou.
> 
> 
> 
> 
> Díky,
> 
> R.
> 
> -- Původní e-mail --
> Od: Jan Macura 
> Komu: OpenStreetMap Czech Republic 
> Datum: 2. 1. 2020 11:41:40
> Předmět: Re: [talk-cz] [začátečníci] wikipedie k place=* 
> "
> 
> +1
> 
> Hlavně za to propojení na Wikidata.
> 
> 
> 
> 
> H.
> 
> 
> 
> 
> 
> On Wed, 1 Jan 2020 at 22:59, Miroslav Suchý  (mailto:miros...@suchy.cz)> wrote:  
> 
> "Ahoj,
> asi zde máme nějaké nováčky, kteří hledají své místo na slunci. Rádi 
> byste zkusili zmapovat něco a myslíte si, že vše podstatné je zmapováno?
> Zkusím vám každý měsíc dát tip na jednoduchý úkol. Jednoduchý v tom, že 
> nevyždaduje předchozí zkušenosti. Ale je toho hodně k zmapování. Takže 
> na vás určitě zbyde... :)
> 
> Úkol na leden
> =
> 
> Máme zmapované všechny vesnice. Ale hodně jich nemá přiřazeno heslo z 
> Wikipedie. Přitom většina turistických aplikací odkaz na wikipedii 
> využívá k zobrazení podrobností o obci. A skoro každá vesnice už dnes má 
> vlastní heslo na Wikipedii. Takže: přiřadit vesnici heslo z wikipedie!
> 
> V Overpass turbo můžete spustit tento dotaz:
> https://overpass-turbo.eu/s/PnN(https://overpass-turbo.eu/s/PnN)
> ```
> 
> [out:json][timeout:25];
> (
>    node["place"="village"][!"wikipedia"]({{bbox}});
>  );
> // print results
> out body;
>  >;  
>  out skel qt;
> 
> ```
> 
> 
> Najděte si oblast, která vás zajímá. A klikněte na Spustit.
> Tento dotaz nalezne všechny vesnice, které nemají atribitut wikipedie.
> 
> Já si, dejme tomu, vyberu Domašov:
>    https://www.openstreetmap.org/node/1601617498
> (https://www.openstreetmap.org/node/1601617498)
>  
> Najděte tuto obec na Wikipedii. V mém případě
>    https://cs.wikipedia.org/wiki/Domašov
> (https://cs.wikipedia.org/wiki/Doma%C5%A1ov)
>  Vetšinou v pravém info boxu jsou zeměpisné souřadnice. Po kliknutí na ně 
> si je můžete otevřít v různých mapách a ověřit si, že jste si vybrali 
> správnou obec.
> 
> Otevřete si svůj editor OpenStreetMap (iD nebo JOSM nebo cokoliv jiného).
> Na uzel té vesnice (tj. place=village) přidejte další atribut 
> wikipedia=cs:Domašov neboli obecně: vemto ten text za posledním lomítkem 
> v tom URL wikipedie a přidejte to za "cs:" v atributu wikipedia.
> Například pro
>    https://cs.wikipedia.org/wiki/%C5%98%C3%AD%C4%8Dany_(okres_Brno-venkov)
> (https://cs.wikipedia.org/wiki/%C5%98%C3%AD%C4%8Dany_(okres_Brno-venkov))
>  by to bylo
>    wikipedia=cs:Říčany_(okres_Brno-venkov)
>  
> Pokud použijete iD editor (to je ten co se nastartuje když kliknete na 
> "Upravit" na stránce openstreetmap.org(http://openstreetmap.org)), tak vám 
> zkusí hned i doplnit 
> atribut "wikidata". Pokud to nevyplní automaticky, tak můžete kliknout 
> do prázného políčka Wikidata a v dropdown menu vybrat správnou hodnotu. 
> V takovém případě klikněte na ten čtvereček se šipkou (view on 
> wikidata), což vás dostane sem:
>    https://www.wikidata.org/wiki/Q761824
> (https://www.wikidata.org/wiki/Q761824)
>  a v záložce "coordinate locatation" se ujistěte, že se jedná o správnou 
> obec.
> 
> A nyní už stačí jenom

Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir

2020-01-03 Diskussionsfäden Bibi via Talk-fr

Ne pas caricaturer ce que dit Julien.
Il dit, et je suis d'accord avec lui, d'intégrer les lieu-dits en bonne 
intelligence.

Si un moulin est isolé on tague le moulin mais si autour du moulin il y a 
quelques maisons on aura un isolated_dwelling.
Il pourra donner son nom à quartier et à un tas d'équipements même si on n'a 
perdu la trace du moulin d'origine.
Le Moulin-Blanc est un sous quartier de Saint-Marc à Brest. Était-ce à 
l'origine un moulin sur le ruisseau ? Sans doute mais ici peu importe il a 
toute sa place dans OSM.

À l'opposé certains lieux-dits n'ont guere de sens.
Je pense à "la pièce pointue" qui correspond à la forme pointue de la parcelle. 
Le démembrement est passé par là et la parcelle en jouxte d'autres de même 
nature.
À quoi bon mettre l'info dans OSM ?


Jean-Yvon
> Von: "Cyrille37 OSM - cyrille+talk...@giquello.fr"


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

[OSM-talk-fr] Blocage de oc-OpenStreetMap [était Re: pb sur un cset lié aux langues locales]

2020-01-03 Diskussionsfäden Vincent Bergeot


Bonjour,

je suis également étonné par les tailles de changesets de cet 
utilisateur 
(https://www.openstreetmap.org/user/oc-OpenStreetMap/history#map=6/45.506/1.861).


Cela me pose plusieurs questions :

- peu d'informations sur les commentaires de changesets, toujours pareil 
: name:oc localization
- pas d'informations sur le compte : 
https://www.openstreetmap.org/user/oc-OpenStreetMap : l'utilisation 
d'openstreetmap dans le nom, laissant penser à un compte "officiel"
- de plus les changesets sont tous conséquents 'entre 8000 et 1 
objets modifiés", avec des intervalles courtes entre, ...
- et sans avoir vérifié mais dans beaucoup de cas c'est "juste" de 
l'ajout d'une source ieo-bdtopoc comme ici 
https://www.openstreetmap.org/way/743094652/history

- le rythme est très soutenu (trop soutenu je pense)


J'ai fait un commentaire ici : 
https://www.openstreetmap.org/changeset/79146537#map=8/44.099/5.845


à bloquer je pense




Le 02/01/2020 à 16:34, Landry Breuil a écrit :

Hello,

pas fait d'OSM depuis un bail, mais en me promenant dans un coin que je
connais bien (lieu dit nommé 'le pous' ou 'lou pous' sur les panneaux
sur place), dans osmand (et sur la carte d'osm.org) j'ai eu la surprise
de voir 'Le Potz' qui est un nom completement inconnu sur place. - le
nom était correct pour moi auparavant (cf
https://www.openstreetmap.org/node/2077266629/history il y'a 8 mois), et
a été modifié par oc-OpenStreetMap dans le changeset
https://www.openstreetmap.org/changeset/70878777 .

Pour moi ce changement est incorrect pour les tags name et name:fr qui
devraient a minima être name:fr='Le Pous' et/ou name='Lou Pous', et
après etre rentré en contact avec l'utilisateur (qui est clairement un
défenseur de la langue occitane?) via la messagerie du site, je n'arrive
pas a un consensus. Je ne vais pas rapporter ici nos échanges qui sont a
mon avis rapidement peu constructifs.

Dans OSM le terrain a toujours primé, les panneaux du lieu dit utilisent
'Lou Pous', les panneaux indicateurs de rando 'Le Pous', nulle part je
n'ai vu 'Le Potz'. Peu importe l'étymologie, la linguistique et la
défense des langues locales, selon moi la base est maintenant fausse.

Est-ce que qqn peut m'éclairer sur ce point ?

merci!

Landry

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



--
Vincent Bergeot


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

Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir