Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-13 00:15, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> Il giorno 13 feb 2020, alle ore 00:05, Colin Smale  
>> ha scritto:
>> 
>> Locations are stored in OSM as pairs of {lat,lon} and I assume these are 
>> both 64-bit floats in the database.
> 
> AFAIK they are stored as integers (shifting the decimals)

If so then then my comments about preserving precision still apply to
all "client" software and I bet the majority uses float. Then an
innocent update to a tag on a node can end up unintentionally moving the
location slightly, losing precision.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Philippe Verdy]

Des admin_level=8 correspondent à plusieurs statuts communaux, ayant un
conseil élu et une autonomie financière (communes simples, communes
nouvelles, associations de communes, communes spéciales à arrondissements),
ou pas (mais qui ont une identité administrative inclue dans une entité
plus grande dont elle fait partie du découpage).

Dans le Pacifique il n'y a pas toujours un admin_centre désigné car les
compétences sont sur plusieurs iles simultanément, les conseils ont bien un
adresse postale, mais le lieu des conseils peut changer (conseils
itinérants) et les services communaux sont répartis sur les iles qui ont
des sortes de "mairies annexes" pour la représentation publique, la plupart
des iles étant de tous petits villages, ou les iles ayant des populations
très saisonnières, et une grande partie des services sont en fait délégués
à un service territorial qui centralise gestion pour chaque commune pour
des économies de moyens (cela est conjugué aux difficultés de transport et
aux coûts). Les communes ont pourtant une entité juridique et une autonomie
comptable mais le gros de leur travail est délégué sur chacune des iles par
des conseils locaux, la commune validant leurs décisions (où figurent aussi
des conseils de droit coutumier qui ne suivent pas non plus la logique du
découpage communal). Les communes sont assez théoriques, en pratique ce
sont les conseils "îliens" (réunis autour des conseillers locaux élus dans
la commune pour représenter chaque ile) qui font le travail et travaillent
pour plusieurs collectivités (la commune, le territoire, et le domaine
coutumier) et sous la supervision préfectorale/haut-commissariat pour
valider les décisions. C'est beaucoup moins centralisé et hiérarchisé qu'en
métropole.

C'est le cas en Polynésie, à Wallis-et-Futuna et en nouvelle-Calédonie où
le droit coutumier est reconnu et où cohabitent plusieurs domaines publics,
que les communes ne représentent pas et ne peuvent décider seules.

Se baser uniquement sur admin_level=8 et boundary=adminsitrative ne permet
pas de différencier tous les cas. C'est pour ça qu'on a des
"admin_type:FR=*" différents. Les statuts "communaux" ont même tendance à
se multiplier (et cela va continuer avec les fusions de compétence)
l'admin_level=8 désigne juste des communes ou *assimilées*, nécessaires
pour assurer la complétude du découpage territorial des entités
territoriales plus grandes.

Le jeu. 13 févr. 2020 à 04:56, Jérôme Amagat  a
écrit :

>
>
> Le mer. 12 févr. 2020 à 19:20,  a
> écrit :
>
>> Le 12/02/2020 à 18:02, Christian Quest - cqu...@openstreetmap.fr a
>> écrit :
>>
>> place=municipality est dans un tableau "administratively declared
>> places", ce qui va très bien avec nos communes nouvelles rurales. Il est
>> par contre très peu utilisé: quelques milliers à peine sur le monde entier
>> !
>>
>> On ne va pas non plus en ajouter des milliers
>> 
>> (713).
>>
>>  Ce ne sont pas que des communes nouvelles ! et certaines communes
> nouvelles portent le nom d'une ville ou d'un village.
>
> J'ai fait cette requête sur overpass turbo :
> https://overpass-turbo.eu/s/QFS
> On peut faire des truc bien compliqué maintenant ! c'est la première fois
> que j'y utilise un if :)
>
> Et j'obtiens 943 communes qui n'ont pas comme nom celui de leur
> admin_centre.
>
> dans le tas il y en a une quinzaine qui n'ont pas d'admin_centre
> tout est dans le pacifique en Polynésie et Clipperton (qui n'est pas une
> commune mais qui a sa relation admin_level=8 ?)
> sauf un truc (créé par Philippe) une relation admin_level=8 pour le
> domaine public maritime dans le golfe du morbillan :
> https://www.openstreetmap.org/relation/8687577
> relation inutile d’après moi.
>
> Il y en a 513 avec le tag admin_type:FR=commune nouvelle donc le reste
> (~400) a priori des communes qui n'ont pas bougé ses dernière années.
>
> Il y en a peut être un peu moins que ça, en regardant rapidement je vois
> des trucs bizarres :
> un name=Saint-Pierre-d'Entremont (Isère) et un
> name=Saint-Pierre-d'Entremont (Savoie)
> Rémire-Montjoly écrit avec ou sens accens.
>
> Je vois un autre problème non lié aux noms :
> "Matis73" a changer des place=village en place=quarter dans les alpes
>
> Comme évoqué par Florimond, il y a le cas des noms de villages et de
> communes avec "-sur-machin", '-en-bidule",... il y en a plein la France
> mais il ont souvent été ajouté au 20e siècle au nom du village ou de la
> ville. Je suis totalement contre les enlever du nom des villages mais que
> fait t on pour les nouveaux créé avec l’arrivée des communes nouvelles ?
> Cherbourg-en-Cotentin, Neuvéglise-sur-Truyère  c'est pas encore rentré
> dans les tête comme un changement du nom de la ville ou du village donc on
> les laisse comme nom de commune mais pas plus ou on les intègre au name des
> villes et villages ou en alt_name?
> ___
> Talk-fr mailing list
> 

Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Jérôme Amagat]

Le mer. 12 févr. 2020 à 19:20,  a écrit :

> Le 12/02/2020 à 18:02, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> place=municipality est dans un tableau "administratively declared places",
> ce qui va très bien avec nos communes nouvelles rurales. Il est par contre
> très peu utilisé: quelques milliers à peine sur le monde entier !
>
> On ne va pas non plus en ajouter des milliers
> 
> (713).
>
>  Ce ne sont pas que des communes nouvelles ! et certaines communes
nouvelles portent le nom d'une ville ou d'un village.

J'ai fait cette requête sur overpass turbo : https://overpass-turbo.eu/s/QFS
On peut faire des truc bien compliqué maintenant ! c'est la première fois
que j'y utilise un if :)

Et j'obtiens 943 communes qui n'ont pas comme nom celui de leur
admin_centre.

dans le tas il y en a une quinzaine qui n'ont pas d'admin_centre
tout est dans le pacifique en Polynésie et Clipperton (qui n'est pas une
commune mais qui a sa relation admin_level=8 ?)
sauf un truc (créé par Philippe) une relation admin_level=8 pour le domaine
public maritime dans le golfe du morbillan :
https://www.openstreetmap.org/relation/8687577
relation inutile d’après moi.

Il y en a 513 avec le tag admin_type:FR=commune nouvelle donc le reste
(~400) a priori des communes qui n'ont pas bougé ses dernière années.

Il y en a peut être un peu moins que ça, en regardant rapidement je vois
des trucs bizarres :
un name=Saint-Pierre-d'Entremont (Isère) et un
name=Saint-Pierre-d'Entremont (Savoie)
Rémire-Montjoly écrit avec ou sens accens.

Je vois un autre problème non lié aux noms :
"Matis73" a changer des place=village en place=quarter dans les alpes

Comme évoqué par Florimond, il y a le cas des noms de villages et de
communes avec "-sur-machin", '-en-bidule",... il y en a plein la France
mais il ont souvent été ajouté au 20e siècle au nom du village ou de la
ville. Je suis totalement contre les enlever du nom des villages mais que
fait t on pour les nouveaux créé avec l’arrivée des communes nouvelles ?
Cherbourg-en-Cotentin, Neuvéglise-sur-Truyère  c'est pas encore rentré
dans les tête comme un changement du nom de la ville ou du village donc on
les laisse comme nom de commune mais pas plus ou on les intègre au name des
villes et villages ou en alt_name?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-ja] いたずら目的の POI?

[Satoshi IIDA]

いいだです。
ベトナム語翻訳でnameの翻訳などみてみましたが、
明らかにいたずら or 間違い編集っぽかったので、リバートしておきました。

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


2020年2月12日(水) 20:46 ISHIKAWA Takayuki (Talk-ja 経由) <
talk-ja@openstreetmap.org>:

> こんにちは、奈良の石川です。
>
> 以下の POI
>
>
> https://www.openstreetmap.org/node/7003777889
>
>
> について、「こんな場所に動物病院ができたのかな」と思い、本日たまたま近くを通ることがあったので現場にいってみましたが、自治会の集会所があるだけで動物病院などありませんでした。
>
> そもそもこの POI について、
>
> ・日本国内の住宅街なのにベトナム語 (ベトナム料理店ならベトナム語でもおかしくないですが…)
> ・名称を Google 翻訳にかけると「トーアンの犬小屋」と出てくる
> ・同じ changeset には「」などというふざけた名称もある
> ・同じ changeset には「nhà tôi」(私の家) という POI がある
> ・この changese 自体、日本からベトナムにかけて広すぎる範囲である
> ・POI を作成した方はこの changeset しか編集していない
>
>
> という状態です。いたずら目的かなぁ、と思うのですが、こういう場合、どのように対処するものでしょうか。(どなたか慣れている方が対処していただけると助かるのですが…。)
>
> --
> 石川
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk] Forests are mappable - was: Re: OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Warin]

The problem?

Large areas of blank map that, when viewed zoomed out, look to be tree 
covered areas.


Result:

Initial mappers tag the large areas as tree covered, ignoring details 
such as lakes, tree cuttings etc.


Some time later details of lakes, tree cuts are added. this may be some 
years later.


This is simple evolution of the map - more detail as time goes by. there 
is no bad intention with any of the mappers, just trying to give some 
impression of what is there.


Problems arise when the source used it not good enough to really say 
what is there, a swamp may look like a patch of grass, or heath ... if 
you simply go by imagery then I think this is bad practice.



On 13/2/20 8:13 am, Pierre Béland via talk wrote:

Hi Mateusz

The link below shows north of Canada areas, where the wood landcover 
correspond in general to Canvec imports. The blank areas are mostly 
not mapped yet except some lakes and infrastructures.

https://www.openstreetmap.org/#map=5/55.740/-79.804

But for Labrador, the contributors have made the choice to import 
Canvec excluding the wood landcover. If someone wants to test how easy 
it is to add the wood landcover, there is quite some work to do there 
creating multipolygons with inner roles for lakes, cuts for Power 
lines, etc.

https://www.openstreetmap.org/#map=9/53.4595/-63.9679

Pierre


Feb 12 r 2020 13 h 30 min 57 s UTC−5, Mateusz Konieczny wrote :


Hard to say more or verify without getting specific location but I 
cleaned up some places
mangled by badly done forest imports - for example border area that 
was hit with multiple

low quality imports.

But it sounds exactly like 
https://www.openstreetmap.org/user/Abbe98/diary/28368
that was solved by splitting unreasonably large relation in parts (by 
deleting it

and remapping)


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



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

Re: [Talk-br] Nova proposta de classificação viária

[santamariense]

Olá pessoal,

Dando prosseguimento a nova proposta de classificação viária, gostaria
de compartilhar com vocês a lista de cidades interconectáveis em forma
de tabela e de mapa esquemático. Neste material já estão consideradas
as cidades conurbadas como sendo apenas uma, bem como também já está
considerado o esquema das conexões internacionais. Gostaria que
analisassem o material pois ele norteará o mapa com a nova
classificação que criaremos em conjunto com a comunidade.

Há uma alta taxa de potenciais trunks na região sudeste. Vale lembrar
ainda que temos alguns pontos que deverão ser discutidos à parte, os
quais estão relacionados em seção específica da wiki da proposta [1].
Esses pontos são os que forem elencados no decorrer da proposta e dela
divergir pontualmente, mas não da ideia geral.

Quanto ao método a adotar para mapear as interconexões, uma
possibilidade é começar pelo par cuja população somada for maior e ir
até a menor. Quanto mais se avançar na tabela, maior a probabilidade
das conexões entre cidades convergirem para conexões existentes
maiores.

Os arquivos estão disponíveis para download em [2]

Como utilizar no JOSM:

1 - Ativar a janela filtro no menu janelas
2 - Botão "+" para adicionar filtros
3 - Exemplo. Para ver todas as interconexões highway=trunk, adicione
novo filtro, onde deve ter ativado o E, H e I
4 - Para ver quantas conexões desse tipo tem uma cidade, selecione-a e
tecle "shift+E" para selecionar as conexões ou "E" para selecionar as
cidades interconectadas (estará selecionada todas as cidades incluido
a primeira).


[1] - 
https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_das_rodovias_do_Brasil

[2] - 
https://github.com/santamariense/ClassViarBR/blob/master/Mapa%20esquem%C3%A1tico%20e%20Tabela%20v20200212.zip

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

Re: [talk-au] Remote mapping of a fence

[Ewen Hill]

Andrew et al,
   The mapper may have used an out of copyright map or document. Is the
fence still in use or has myxo and Calicivirus made it redundant?

On Thu, 13 Feb 2020 at 10:17, Andrew Harvey 
wrote:

> Warin, thanks for raising. I've asked the mapper to confirm their sources,
> I'll see what they say first.
>
> Mike, good point. As it stands due to reasons given at
> https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/ we need a
> waiver to use CC BY data in OSM. In Queensland as listed at
> https://wiki.openstreetmap.org/wiki/Australian_data_catalogue we've got
> that waiver from TMR for state control roads surveyed centerline, Protected
> Areas of Queensland, Brisbane City Council, Noosa Shire Council and City of
> Townsville, but no other sources.
>
> If someone want's to use this data to improve OSM the first step is we'll
> need to approach Department of Agriculture and Fisheries for this CC BY
> waiver.
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>


-- 
Warm Regards

Ewen Hill
Internet Development Australia
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[marc marc]

Le 12.02.20 à 23:02, Victor/tuxayo a écrit :
> Est-ce qu'il aurai a un moyen pour indiquer l'absence de panneau alors
> que c'est légalement requis? (caméra dans un lieu publique en France par
> exemple)

perso je suis fan de l'extention de unsigned sous forme
de  unsigned=
exemple unsigned=addr:housenumber : la plaque du no est absente
sur le terrain (mais l'info est vérifiable en opendata par ex)
donc dans ton cas, quand tu auras trouvé comment renseigner le panneau,
tu auras le moyen de renseigner son absence :-D
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Philippe Verdy]

là je suis d'accord, cette information est générale et ne vise pas
spécialement les touristes mais tout le monde.

On peut comparer avec la situation des panneau d'affichage électoraux qui
eux ne visent pas du tout les "touristes" mais les électeurs résidents et
qui n'ont rien à faire dans la catégorie tourisme.
De même pour les panneaux d'annonces légales.

Bref la clé de base importante, c'est "information=board" pour tout panneau
d'information plus "board_type=*" (qu'on peut compléter par
"tourism=information" *seulement* quand l'information affichée a une valeur
touristique).

Il n'y a pas de raison de "chaîner" les tags pour ce qui ne doit pas
l'être, car cela ajoute des restrictions fausses.





Le jeu. 13 févr. 2020 à 00:04, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :

> Relis mon mail...
>
> Ça serait bien que les sous clés ou les valeurs ne violent pas la
> définition de la clé principale, non ?
> J'en remet une couche :
> «Places and things of specific interest to tourists including places to
> see, places to stay, things and *places providing information and support
> to tourists.*»
> https://wiki.openstreetmap.org/wiki/Key:tourism
>
> On est là pour faire une base de données (facilement) utilisable ou pas ?
>
> Tout ce que je propose c'est juste ne pas mettre tourism=information,
> moins de travail.
>
> Le mer. 12 févr. 2020 à 22:40, Victor/tuxayo  a écrit :
>
>> On 20-02-12 22:05, Florimond Berthoux wrote:
>> > Le problème c'est que les consommateurs de cette données vont
>> > l'interpréter comme une information touristique alors que ça ne l'est
>> pas.
>> > Exemple, ça sera affiché sur CyclOSM comme n'importe qu'elle autre
>> > panneau d'info à valeur touristique.
>>
>> On tombe dans le problème que les consommateurs ne doivent pas se fier
>> uniquement aux clefs et aux valeurs mais à la documentation.
>> Sans la doc, il y a un nombre énorme de clefs+valeurs qui seraient mal
>> interprétés.
>>
>> À++
>>
>> --
>> Victor/tuxayo
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> 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-au] Remote mapping of a fence

[Andrew Harvey]

Warin, thanks for raising. I've asked the mapper to confirm their sources,
I'll see what they say first.

Mike, good point. As it stands due to reasons given at
https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/ we need a
waiver to use CC BY data in OSM. In Queensland as listed at
https://wiki.openstreetmap.org/wiki/Australian_data_catalogue we've got
that waiver from TMR for state control roads surveyed centerline, Protected
Areas of Queensland, Brisbane City Council, Noosa Shire Council and City of
Townsville, but no other sources.

If someone want's to use this data to improve OSM the first step is we'll
need to approach Department of Agriculture and Fisheries for this CC BY
waiver.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Martin Koppenhoefer]

sent from a phone

> Il giorno 13 feb 2020, alle ore 00:05, Colin Smale  ha 
> scritto:
> 
> Locations are stored in OSM as pairs of {lat,lon} and I assume these are both 
> 64-bit floats in the database.


AFAIK they are stored as integers (shifting the decimals)


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

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-12 23:34, Martin Koppenhoefer wrote:

> sent from a phone
> 
> Il giorno 12 feb 2020, alle ore 14:06, Colin Smale  ha 
> scritto:
> 
> Exactly this. A hobbyist or volunteer CAN verify an admin boundary (where it 
> is available as open data) - it is independently verifiable. It is 
> objectively of better quality than an OTG observation with a phone.
> 
> this will obviously depend on the individual case, but in some instances in 
> Europe I have seen the published open data boundaries were simplified 
> geometries. Just because the original datum was precisely acquired doesn't 
> necessarily imply that the published open data (often derivative data) is 
> super accurate as well (our own errors in the transformation of the data 
> during the import aside).

Good point about the simplification. If they do that by Douglas Peuker
then no points will be moved, but some points can be deleted. So any
points that make it through to the simplified data are accurate and
actually appear in the input. If the boundary, road or whatever is
actually curved, then we can subjectively improve on the published data
by inserting additional points, but we should use the accurate points as
a frame of reference and *leave them alone*. They are most likely to be
the very best data we can get our hands on, even if they are not 100%. 

Concerning data quality and its definition: 
Locations are stored in OSM as pairs of {lat,lon} and I assume these are
both 64-bit floats in the database. Any processing that we do on any
location should be done so as to minimise the error, so the
transformation parameters should be as accurate as possible and all
operations should be done at maximum precision - 64-bit floats ("double
precision" for the old guard) or, even better, 128-bit. When processing
this kind of data you need to be aware of these things, and principles
like these should also be considered "best practices". Results from
higher-precision inputs using higher-precision operations can be
considered to be *of a higher quality* than when a lower precision is
used. And when we "export" the data by translating the binary
representation to text (including XML), that should also be at a
sufficiently high precision, such that re-importing the data would lead
to the same binary representation. Every time data is loaded into an
editor, it is translated to a string, and when it is stored, it
translated back. This process must not lead to a loss of data precision!___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Florimond Berthoux]

Relis mon mail...

Ça serait bien que les sous clés ou les valeurs ne violent pas la
définition de la clé principale, non ?
J'en remet une couche :
«Places and things of specific interest to tourists including places to
see, places to stay, things and *places providing information and support
to tourists.*»
https://wiki.openstreetmap.org/wiki/Key:tourism

On est là pour faire une base de données (facilement) utilisable ou pas ?

Tout ce que je propose c'est juste ne pas mettre tourism=information, moins
de travail.

Le mer. 12 févr. 2020 à 22:40, Victor/tuxayo  a écrit :

> On 20-02-12 22:05, Florimond Berthoux wrote:
> > Le problème c'est que les consommateurs de cette données vont
> > l'interpréter comme une information touristique alors que ça ne l'est
> pas.
> > Exemple, ça sera affiché sur CyclOSM comme n'importe qu'elle autre
> > panneau d'info à valeur touristique.
>
> On tombe dans le problème que les consommateurs ne doivent pas se fier
> uniquement aux clefs et aux valeurs mais à la documentation.
> Sans la doc, il y a un nombre énorme de clefs+valeurs qui seraient mal
> interprétés.
>
> À++
>
> --
> Victor/tuxayo
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [Talk-it] centro riparazione elettrodomestici

[Martin Koppenhoefer]

sent from a phone

> Il giorno 12 feb 2020, alle ore 19:03, liste DOT girarsi AT posteo DOT eu 
>  ha scritto:
> 
> C'è un futures messo come obsoleto che propone:
> 
> craft=electronics_repair
> 
> electronics_repair=appliance


electronics non è la stessa cosa di elettrodomestici. Sono oggetti elettronici 
(cellulari, computer, hifi, ecc). Un aspirapolvere o forno o ferro da stiro non 
è elettronico (potrebbe avere componenti elettronici, ma principalmente non è 
elettronico e funzionerebbe anche senza)

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

Re: [talk-au] Remote mapping of a fence

[Mike King]

Hi there

Queensland Governments open data is quite extensive.  I would discourage 
digitizing of this fence in favour of importing the actual data available from 
the Agriculture department

Metadata (read more at: 
http://qldspatial.information.qld.gov.au/catalogue/custom/viewMetadataDetails.page?uuid=%7B5E9EC7FB-99EE-4B2A-A43D-81FA0E44578D%7D
 )


Mike

-Original Message-
From: Warin [mailto:61sundow...@gmail.com]
Sent: Thursday, 13 February 2020 8:07 AM
To: talk-au
Subject: [talk-au] Remote mapping of a fence

Hi,


A remote mapper is adding a fence line to OSM.

I believe the imagery detail is not sufficient to map this fence alone.


See relation 10703889 (https://www.openstreetmap.org/relation/10703889).


I think the remote mapper is using the website https://www.ddmrb.org.au/
to establish where the fence is then using a very faint trace in imagery
to state there is a fence here.

Note https://www.ddmrb.org.au/copywrite/ - for private use only.


Thoughts?


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


Warning: This email (which includes all attachments and linked documents) is 
intended for and is confidential to the addressee; it may also be subject to 
copyright, legal professional privilege or otherwise protected from disclosure. 
If you are not the addressee, or if you have received this email in error, you 
must not use, rely upon, disclose or reproduce it (or any part of it) in any 
way. Please notify the sender of your receipt of it and delete it in its 
entirety. The National Heavy Vehicle Regulator does not accept any liability 
for computer viruses, data corruption, delay, interference, interception, 
unauthorised access or amendment of this email.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Remote mapping of a fence

[cleary]

I agree with your concern. Some imagery may permit an experienced eye to 
identify a fence line. However identification of a particular fence by name 
would need more than the satellite imagery. If the source of other info 
including name is copyrighted, then it's inclusion in OSM is not appropriate. 



On Thu, 13 Feb 2020, at 9:07 AM, Warin wrote:
> Hi,
> 
> 
> A remote mapper is adding a fence line to OSM.
> 
> I believe the imagery detail is not sufficient to map this fence alone.
> 
> 
> See relation 10703889 (https://www.openstreetmap.org/relation/10703889).
> 
> 
> I think the remote mapper is using the website https://www.ddmrb.org.au/ 
> to establish where the fence is then using a very faint trace in imagery 
> to state there is a fence here.
> 
> Note https://www.ddmrb.org.au/copywrite/ - for private use only.
> 
> 
> Thoughts?
> 
> 
> ___
> 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: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Florimond Berthoux]

Visitor :
« someone who visits
 a person
 or place
:»
https://dictionary.cambridge.org/fr/dictionnaire/anglais/visitor

Visit :
« to go to a place *in order to look at it*, or to a person in order to
spend time with them:»
https://dictionary.cambridge.org/fr/dictionnaire/anglais/visit

British English, OSM tout ça...


Le mer. 12 févr. 2020 à 22:35, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> C'est pas chez toi donc t'es un visiteur suivi d'un consommateur
>
> Le mer. 12 févr. 2020 à 22:06, Florimond Berthoux <
> florimond.berth...@gmail.com> a écrit :
>
>> «An *information* source for tourists, travellers and visitors.»
>> Je visite rarement les supermarchés, les halls d'entreprises ou les
>> piscines municipales.
>> J'y vais mais je ne visite pas.
>>
>> Le problème c'est que les consommateurs de cette données vont
>> l'interpréter comme une information touristique alors que ça ne l'est pas.
>> Exemple, ça sera affiché sur CyclOSM comme n'importe qu'elle autre
>> panneau d'info à valeur touristique.
>>
>> (Pour préciser, je ne suis contre que sur l'utilisation du tag 
>> tourism=information
>> pour ce cas)
>>
>>
>> Le mer. 12 févr. 2020 à 21:07,  a
>> écrit :
>>
>>> Si on regarde ce qui touche à la surveillance côté taginfo:
>>>
>>> surveillance=outdoor/public/indoor.
>>> surveillance:type=camera
>>> surveillance:zone=traffic/building/town/parking...
>>>
>>> Ça me semble possible de l'indiquer aussi ici.
>>>
>>> Certes ce n'est pas du tourisme mais board_type=sport ou
>>> board_type=public_transport non plus.
>>>
>>> Simplement on a/aurait la chaîne tourism=information / information=board
>>> / board_type=surveillance.
>>>
>>> C'est bien ce qu'a écrit Shohreh
>>> 
>>> sur le wiki.
>>>
>>> Et non ça ne me choque pas. Même si la caméra n'a pas de reconnaissance
>>> faciale pour ne fliquer que les touristes^^.
>>>
>>> Jean-Yvon
>>> Le 12/02/2020 à 20:49, Florimond Berthoux - florimond.berth...@gmail.com
>>> a écrit :
>>>
>>> Mon avis que ce tourism=information est une erreur, il y a rien de
>>> touristique dans ce panneau.
>>> information=board et board_type=* se suffisent à eux même.
>>>
>>> Le mar. 11 févr. 2020 à 16:27, Shohreh  a écrit :
>>>
 Ok, donc c'est parti pour

 tourism=information
 information=board
 board_type=surveillance

 Merci.
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> --
>> 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
>


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

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[osm . sanspourriel]

D'accord avec Jérôme, sinon une caméra qui ne respecte pas la loi on la
fait enlever.

Éventuellement on ajoute une clé style legal=no ou
law_violation=missing_sign...

Juste une idée à mûrir : c'est bien par rapport à la caméra qui existe
que quelque chose manque.

Données exploitables dans une umap par exemple.

Peut-être voir ce que font les RAP par rapport à la publicité illégale.

Jean-Yvon

Le 12/02/2020 à 23:14, Jérôme Seigneuret - jerome.seigneu...@gmail.com a
écrit :

On tag l'existant pas le manque mais une umap avec un symbologie
propre au caméra les panneaux d'entrée de ville et la panneau
d'information de ville sous vidéo surveillance devrait faire ton affaire

Le mer. 12 févr. 2020 à 23:03, Victor/tuxayo mailto:vic...@tuxayo.net>> a écrit :

On 20-02-11 16:26, Shohreh wrote:
> tourism=information
> information=board
> board_type=surveillance

Est-ce qu'il aurai a un moyen pour indiquer l'absence de panneau
alors
que c'est légalement requis? (caméra dans un lieu publique en
France par
exemple)

Car là on peut juste indiquer la présence d'un panneau.

Cas concret: Dans le cadre de contribuer à la campagne
Technopolice[1] à
Marseille, il y a pour plan de faire une cartopartie des caméras de
surveillance.
Et pour aller plus loin, des gens seraient intéressés par indiquer si
une caméra viole la législation sur l'affichage. Et de les
extraire sur
une carte pour que cela serve lors de plaintes.[2] (à différents buts
dont obtenir en open data la position des caméras de certaines villes)

Donc cette discussion tombe très bien :D Est-ce que qu'un a une idée
pour indiquer de manière propre l'absence de signalétique d'une
caméra?
Au pire écrire un truc joli dans l’attribut "description" (ou un truc
pas joli dans "note") et homogénéiser ce qu'il y est mit à l'échelle
d'une ville mais c'est du gros bricolage. (non)

À++

[1] https://technopolice.fr/
[2]

https://forum.technopolice.fr/topic/403/plainte-collective-cnil-obliger-paris-%C3%A0-publier-une-carte-de-ses-cam%C3%A9ras

--
Victor/tuxayo

___
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] Demande d'intervention de tiers sur un conflit d'édition

[Thomas Ruchin]

Voici un des échanges que j'avais eu voici quelques mois avec ce
contributeur :
https://www.openstreetmap.org/changeset/62907425
C'est dommage de perdre tant d'énergie, et plutôt désagréable de le croiser
sur sa route.

Thomas


Le mercredi 12 février 2020, Stéphane Péneau  a
écrit :

> Le 12/02/2020 à 13:31, Charles MILLET a écrit :
>
>>
>> Je ne suis pas à l'aise avec l'idée de faire un signalement au DWG car en
>>> dehos de ce genre de comportement, ses contributions sont bonnes.
>>> Pensez-vous qu'il faille le faire ?
>>>
>>
>
> Oui, mais j'ai un point de vue biaisé puisque partie prenante.
>
> Stf
>
>
> ___
> 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] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Martin Koppenhoefer]

sent from a phone

> Il giorno 12 feb 2020, alle ore 14:06, Colin Smale  ha 
> scritto:
> 
> Exactly this. A hobbyist or volunteer CAN verify an admin boundary (where it 
> is available as open data) - it is independently verifiable. It is 
> objectively of better quality than an OTG observation with a phone.


this will obviously depend on the individual case, but in some instances in 
Europe I have seen the published open data boundaries were simplified 
geometries. Just because the original datum was precisely acquired doesn’t 
necessarily imply that the published open data (often derivative data) is super 
accurate as well (our own errors in the transformation of the data during the 
import aside).

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

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Jérôme Seigneuret]

On tag l'existant pas le manque mais une umap avec un symbologie propre au
caméra les panneaux d'entrée de ville et la panneau d'information de ville
sous vidéo surveillance devrait faire ton affaire

Le mer. 12 févr. 2020 à 23:03, Victor/tuxayo  a écrit :

> On 20-02-11 16:26, Shohreh wrote:
> > tourism=information
> > information=board
> > board_type=surveillance
>
> Est-ce qu'il aurai a un moyen pour indiquer l'absence de panneau alors
> que c'est légalement requis? (caméra dans un lieu publique en France par
> exemple)
>
> Car là on peut juste indiquer la présence d'un panneau.
>
> Cas concret: Dans le cadre de contribuer à la campagne Technopolice[1] à
> Marseille, il y a pour plan de faire une cartopartie des caméras de
> surveillance.
> Et pour aller plus loin, des gens seraient intéressés par indiquer si
> une caméra viole la législation sur l'affichage. Et de les extraire sur
> une carte pour que cela serve lors de plaintes.[2] (à différents buts
> dont obtenir en open data la position des caméras de certaines villes)
>
> Donc cette discussion tombe très bien :D Est-ce que qu'un a une idée
> pour indiquer de manière propre l'absence de signalétique d'une caméra?
> Au pire écrire un truc joli dans l’attribut "description" (ou un truc
> pas joli dans "note") et homogénéiser ce qu'il y est mit à l'échelle
> d'une ville mais c'est du gros bricolage. (non)
>
> À++
>
> [1] https://technopolice.fr/
> [2]
>
> https://forum.technopolice.fr/topic/403/plainte-collective-cnil-obliger-paris-%C3%A0-publier-une-carte-de-ses-cam%C3%A9ras
>
> --
> Victor/tuxayo
>
> ___
> 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-au] Remote mapping of a fence

[Warin]

Hi,


A remote mapper is adding a fence line to OSM.

I believe the imagery detail is not sufficient to map this fence alone.


See relation 10703889 (https://www.openstreetmap.org/relation/10703889).


I think the remote mapper is using the website https://www.ddmrb.org.au/ 
to establish where the fence is then using a very faint trace in imagery 
to state there is a fence here.


Note https://www.ddmrb.org.au/copywrite/ - for private use only.


Thoughts?


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

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Victor/tuxayo]

On 20-02-11 16:26, Shohreh wrote:

tourism=information
information=board
board_type=surveillance


Est-ce qu'il aurai a un moyen pour indiquer l'absence de panneau alors 
que c'est légalement requis? (caméra dans un lieu publique en France par 
exemple)


Car là on peut juste indiquer la présence d'un panneau.

Cas concret: Dans le cadre de contribuer à la campagne Technopolice[1] à 
Marseille, il y a pour plan de faire une cartopartie des caméras de 
surveillance.
Et pour aller plus loin, des gens seraient intéressés par indiquer si 
une caméra viole la législation sur l'affichage. Et de les extraire sur 
une carte pour que cela serve lors de plaintes.[2] (à différents buts 
dont obtenir en open data la position des caméras de certaines villes)


Donc cette discussion tombe très bien :D Est-ce que qu'un a une idée 
pour indiquer de manière propre l'absence de signalétique d'une caméra?
Au pire écrire un truc joli dans l’attribut "description" (ou un truc 
pas joli dans "note") et homogénéiser ce qu'il y est mit à l'échelle 
d'une ville mais c'est du gros bricolage. (non)


À++

[1] https://technopolice.fr/
[2] 
https://forum.technopolice.fr/topic/403/plainte-collective-cnil-obliger-paris-%C3%A0-publier-une-carte-de-ses-cam%C3%A9ras


--
Victor/tuxayo

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

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Victor/tuxayo]

On 20-02-12 22:05, Florimond Berthoux wrote:
Le problème c'est que les consommateurs de cette données vont 
l'interpréter comme une information touristique alors que ça ne l'est pas.
Exemple, ça sera affiché sur CyclOSM comme n'importe qu'elle autre 
panneau d'info à valeur touristique.


On tombe dans le problème que les consommateurs ne doivent pas se fier 
uniquement aux clefs et aux valeurs mais à la documentation.
Sans la doc, il y a un nombre énorme de clefs+valeurs qui seraient mal 
interprétés.


À++

--
Victor/tuxayo

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

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Jérôme Seigneuret]

C'est pas chez toi donc t'es un visiteur suivi d'un consommateur

Le mer. 12 févr. 2020 à 22:06, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :

> «An *information* source for tourists, travellers and visitors.»
> Je visite rarement les supermarchés, les halls d'entreprises ou les
> piscines municipales.
> J'y vais mais je ne visite pas.
>
> Le problème c'est que les consommateurs de cette données vont
> l'interpréter comme une information touristique alors que ça ne l'est pas.
> Exemple, ça sera affiché sur CyclOSM comme n'importe qu'elle autre panneau
> d'info à valeur touristique.
>
> (Pour préciser, je ne suis contre que sur l'utilisation du tag 
> tourism=information
> pour ce cas)
>
>
> Le mer. 12 févr. 2020 à 21:07,  a
> écrit :
>
>> Si on regarde ce qui touche à la surveillance côté taginfo:
>>
>> surveillance=outdoor/public/indoor.
>> surveillance:type=camera
>> surveillance:zone=traffic/building/town/parking...
>>
>> Ça me semble possible de l'indiquer aussi ici.
>>
>> Certes ce n'est pas du tourisme mais board_type=sport ou
>> board_type=public_transport non plus.
>>
>> Simplement on a/aurait la chaîne tourism=information / information=board
>> / board_type=surveillance.
>>
>> C'est bien ce qu'a écrit Shohreh
>> 
>> sur le wiki.
>>
>> Et non ça ne me choque pas. Même si la caméra n'a pas de reconnaissance
>> faciale pour ne fliquer que les touristes^^.
>>
>> Jean-Yvon
>> Le 12/02/2020 à 20:49, Florimond Berthoux - florimond.berth...@gmail.com
>> a écrit :
>>
>> Mon avis que ce tourism=information est une erreur, il y a rien de
>> touristique dans ce panneau.
>> information=board et board_type=* se suffisent à eux même.
>>
>> Le mar. 11 févr. 2020 à 16:27, Shohreh  a écrit :
>>
>>> Ok, donc c'est parti pour
>>>
>>> tourism=information
>>> information=board
>>> board_type=surveillance
>>>
>>> Merci.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> 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: [OSM-talk] Forests are mappable - was: Re: OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Pierre Béland via talk]

Hi Mateusz
The link below shows north of Canada areas, where the wood landcover correspond 
in general to Canvec imports. The blank areas are mostly not mapped yet except 
some lakes and 
infrastructures.https://www.openstreetmap.org/#map=5/55.740/-79.804
But for Labrador, the contributors have made the choice to import Canvec 
excluding the wood landcover. If someone wants to test how easy it is to add 
the wood landcover, there is quite some work to do there creating multipolygons 
with inner roles for lakes, cuts for Power lines, etc. 
https://www.openstreetmap.org/#map=9/53.4595/-63.9679 
Pierre 
 

Feb 12 r 2020 13 h 30 min 57 s UTC−5, Mateusz Konieczny wrote :

Hard to say more or verify without getting specific location but I cleaned up 
some places
mangled by badly done forest imports - for example border area that was hit 
with multiple
low quality imports.

But it sounds exactly like https://www.openstreetmap.org/user/Abbe98/diary/28368
that was solved by splitting unreasonably large relation in parts (by deleting 
it
and remapping)

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

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[Florimond Berthoux]

Sur le wiki en créant une page, par exemple en anglais tu suis un des liens
et tu appuies sur "créer"
https://wiki.openstreetmap.org/wiki/Key:pole:sealed
ou https://wiki.openstreetmap.org/wiki/Key:support:sealed

Le mar. 11 févr. 2020 à 21:30,  a écrit :

> Ok, je vais tenter avec cela.
> Pour le documenter, comment ça se passe?
>
> Merci!
>
> --
> *De: *"Florimond Berthoux" 
> *À: *"Discussions sur OSM en français" 
> *Envoyé: *Mardi 11 Février 2020 19:38:44
> *Objet: *Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de
> villes & villages
>
> Tout bien réfléchi je pense que c'est une erreur de considérer le sol ou
> le béton comme étant le support du poteau (c'est pas faux, mais pas top non
> plus).
> Je verrais plutôt un tag pour préciser si le poteau est scellé ou non dans
> du béton.
>
> propositions :
> support:sealed=yes|concrete
> ou
> pole:sealed=yes|concrete
>
> (sealed ou embedded ?)
>
> @Onésime oui il n'y a pas de tag documenté pour différencier les poteaux
> scellé des non scellé.
> Dans l'absolue vaut mieux inventer inventer un nouveau tag, le documenter,
> et s'il faut le changer un peu plus tard on pourra le faire de façon
> presque automatique.
>
> Le mar. 11 févr. 2020 à 14:34, marc marc  a
> écrit :
>
>> Le 11.02.20 à 14:05, Florimond Berthoux a écrit :
>> > support=pole
>> > support:pole:support=ground
>> >
>> > plutôt parce que s’il y a plusieurs support (support=pole;wall) on
>> > pourra pas préciser le support de quel support.
>>
>> une photo d'un panneau supporté à la fois par un poteau et un mur ?
>> j'ai l'impression qu'on est une fois de +  entrain de faire une usine à
>> gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus
>> complexe que le cas par défaut. et le contributeur lambda est largé
>> depuis longtemps par la marche toujours plus grande à entrée...
>>
>> > Le mar. 11 févr. 2020 à 00:15, marc marc a écrit :
>> >
>> > support=pole : le panneau est porté par un poteau
>> > support:support=ground : le poteau est directement mis dans le sol
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> 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
>


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

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Florimond Berthoux]

«An *information* source for tourists, travellers and visitors.»
Je visite rarement les supermarchés, les halls d'entreprises ou les
piscines municipales.
J'y vais mais je ne visite pas.

Le problème c'est que les consommateurs de cette données vont l'interpréter
comme une information touristique alors que ça ne l'est pas.
Exemple, ça sera affiché sur CyclOSM comme n'importe qu'elle autre panneau
d'info à valeur touristique.

(Pour préciser, je ne suis contre que sur l'utilisation du tag
tourism=information
pour ce cas)


Le mer. 12 févr. 2020 à 21:07,  a écrit :

> Si on regarde ce qui touche à la surveillance côté taginfo:
>
> surveillance=outdoor/public/indoor.
> surveillance:type=camera
> surveillance:zone=traffic/building/town/parking...
>
> Ça me semble possible de l'indiquer aussi ici.
>
> Certes ce n'est pas du tourisme mais board_type=sport ou
> board_type=public_transport non plus.
>
> Simplement on a/aurait la chaîne tourism=information / information=board /
> board_type=surveillance.
>
> C'est bien ce qu'a écrit Shohreh
> 
> sur le wiki.
>
> Et non ça ne me choque pas. Même si la caméra n'a pas de reconnaissance
> faciale pour ne fliquer que les touristes^^.
>
> Jean-Yvon
> Le 12/02/2020 à 20:49, Florimond Berthoux - florimond.berth...@gmail.com
> a écrit :
>
> Mon avis que ce tourism=information est une erreur, il y a rien de
> touristique dans ce panneau.
> information=board et board_type=* se suffisent à eux même.
>
> Le mar. 11 févr. 2020 à 16:27, Shohreh  a écrit :
>
>> Ok, donc c'est parti pour
>>
>> tourism=information
>> information=board
>> board_type=surveillance
>>
>> Merci.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[osm . sanspourriel]

Si on regarde ce qui touche à la surveillance côté taginfo:

surveillance=outdoor/public/indoor.
surveillance:type=camera
surveillance:zone=traffic/building/town/parking...

Ça me semble possible de l'indiquer aussi ici.

Certes ce n'est pas du tourisme mais board_type=sport ou
board_type=public_transport non plus.

Simplement on a/aurait la chaîne tourism=information / information=board
/ board_type=surveillance.

C'est bien ce qu'a écrit Shohreh

sur le wiki.

Et non ça ne me choque pas. Même si la caméra n'a pas de reconnaissance
faciale pour ne fliquer que les touristes^^.

Jean-Yvon

Le 12/02/2020 à 20:49, Florimond Berthoux - florimond.berth...@gmail.com
a écrit :

Mon avis que ce tourism=information est une erreur, il y a rien de
touristique dans ce panneau.
information=board et board_type=* se suffisent à eux même.

Le mar. 11 févr. 2020 à 16:27, Shohreh mailto:codecompl...@free.fr>> a écrit :

Ok, donc c'est parti pour

tourism=information
information=board
board_type=surveillance

Merci.

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

Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

[Philippe Verdy]

Attention, on ne peut pas parler de "piste cyclable" quand les cyclistes
sont incités à devoir utiliser un trottoir, déjà peu large car rétréci par
les emplacements de stationnement, les emplacements de dépôt des poubelles
et conteurs de recyclage et des barrières de protection bloquand le passage
des piétons et cyclistes vers la chaussée, et les arbres: les cyclistes
partagent alors le trottoir... mais à pied, ils ne peuvent pas y rouler

(je parle de là où il n'y a pas de "ségrégation" possible des piétons ou
cyclistes faute de place, par au moins un marquage au sol, ou alors ils
doivent rester sur la chaussée séparée (même si ici c'est une nationale
avec un très fort trafic le long de la Seine rive droite vers la Défense).
Un trottoir de moins de 3 mètres de large ne permet pas cette ségrégation,
c'est alors juste un trottoir même si à une extrémité il y a eu une courte
ségrégation ou un fléchage de vélo pour demander aux cyclistes de se
diriger vers le trottoir... et de descendre de vélo avant la fin de
marquage sur quelques mètres.

On peut noter dans cette zone un découpage fin des trottoirs et des places
de stationnement individuelles, et de diverses barrières et plots de
séparation (il y a aussi des difficultés à ces troittoirs concernant les
sorties de parkings privés: rouler sur le trottoir ne donne pas assez de
visibilité, un vélo ne peut pas y rouler en sécurité sans risque pour les
autres usagers du trottoir: entrées/sorties de garages, et piétons. Le
cycliste doit devenir piéton, ce n'est donc plus un piste "cyclable" du
tout, juste un trottoir.


Le mer. 12 févr. 2020 à 15:53, Stéphane Péneau 
a écrit :

> Le 12/02/2020 à 13:31, Charles MILLET a écrit :
> >
> >> Je ne suis pas à l'aise avec l'idée de faire un signalement au DWG
> >> car en dehos de ce genre de comportement, ses contributions sont
> >> bonnes. Pensez-vous qu'il faille le faire ?
>
>
> Oui, mais j'ai un point de vue biaisé puisque partie prenante.
>
> Stf
>
>
> ___
> 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] Tag panneau zone vidéo surveillance ?

[Florimond Berthoux]

Mon avis que ce tourism=information est une erreur, il y a rien de
touristique dans ce panneau.
information=board et board_type=* se suffisent à eux même.

Le mar. 11 févr. 2020 à 16:27, Shohreh  a écrit :

> Ok, donc c'est parti pour
>
> tourism=information
> information=board
> board_type=surveillance
>
> 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
>


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

Re: [Talk-it] vie ferrate e vie di arrampicata

[Alfredo Gattai]

>
>
> Grazie per la spiegazione, ma mi resta il dubbio numero sentiero, cioè
> se la ferrata è parte del sentiero, e quindi un unicum ma che la stessa
> definisce la massima difficoltà per forza di cose, e quindi su OSM fa
> riferimento il tag cai_scale=* e diventa un'unica relazione con i tag
> specifici della ferrata rilasciati sui tratti interessati, e i tratti di
> sentieri tra eventuali ferrate coi rispettivi tag dedicati.
>
>
Per ora il numero rimane quello, se un percorso ha un numero a catasto
rimane valido anche se diventa una ferrata.
Mi aspetto di trovare situazioni particolari da dirimere di volta in volta
ma in linea di massima se ha gia' in ref, rimane quello e tutto il percorso
prendera' la cai_scale adeguata.



> Quindi mi chiedo e ti chiedo, si sta revisionando l'intero catasto CAI
> in modo da definire separatamente sentiero e ferrata, coi numeri
> sentieri ben separati in modo da avere ben distinti i tratti numerati
> sitematicamente?
>
> Per SAT non so, al momento non vedo differenze dall'attuale catasto, su
> OSM, ma mi pare evidente che se si fa a livello nazionale
> inevitabilmente si a a livello regionale.
>
>
>
L'intenzione e' quella, ovviamente ci metteremo un po' e dovremo occuparci
di eventuale pregresso che potrebbe non essere conforme, ma come sempre, di
buona lena si sistema tutto


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

Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Philippe Verdy]

Il serait temps de commencer à réfléchir à la différenciation du découpage
administratif et du découpage urbain du territoire, comme le fait l'INSEE
justement.

Le premier (communes, etc.) évolue à coup de lois et décrets préfectoraux,
le second (agglomérations, zones urbaines) en fonction de l'activité et des
permis de construire ou lotir des communes (et maintenant du PLU communal
ou communautaire devenu obligatoire), mais une décision de lotir ou
construire ne signifie pas qu'il y a une occupation réelle, c'est
désynchronisé dans le temps (et des zones bâties disparaissent aussi par
des démolitions ou reconversions, y compris les démolition sur le littoral
ou les zones inondables).

Le découpage urbain de l'INSEE ne tient donc pas compte du zonage
d'aménagement des communes et de leur PLU mais de la situation réelle, pour
le découpage fin seulement, car au delà l'INSEE fait des regroupements de
communes entières (ou communes déléguées/associées) en incluant à la fois
leur domaine rural et urbain, en prenant le niveau administratif le plus
approprié pour faire ces regroupements statistiques. Ce découpage a une
finalité statistique et devrait donc être de type boundary=statistical (en
dessous du niveau des agglomérations, pour les communes les plus peuplées,
l'INSEE ajoute les RIS qu'on n'a pas encore modélisés, mais correspondent
au modèle du recensement, boundary=census_unit, mais qui ne tient pas
compte du découpage urbain mais des frontières administratives des communes
au niveau 8, ou celles des arrondissements, ou communes déléguées/associées
au niveau 9, ce découpage servant aussi en partie à délimiter les
circonscriptions électorales mais avec des exceptions notamment pour les
cantons, car les seuils dépendent des lois électorales pour "égaliser" la
population sans forcément tenir compte du découpage administratif, ou
statistique en RIS).

Vient ensuite le découpage de la réglementation routière qui définit les
"agglomérations routières" en fonction de la signalisation décidée ou
concertée par les communes et préfets. Ces agglomérations ne correspondent
pas non plus exactement aux agglomérations de l'INSEE. Ce zonage routier
(impliqué par les panneaux EB10/EB20 là où il y en a) est à part et a de
nombreuses exceptions qui ne tiennent pas du tout compte des autres
découpages, mais aussi de la nature des voies, leur équipement, les zones
de danger, la présence d'écoles ou zones sportives et de loisirs, ou encore
des nécessités environnementales.

Ce découpage des agglomérations routières pour l'instant a été tenté en
divers endroits en utilisant une relation "boundary=urban", qui ne me
semble pas être le bon tag mais dont le tracé remplit cet objectif (celui
de définit une limite de vitesse par défaut sur les voies qui y sont
incluses). Mais les limites de vitesse sont compliquées car elles sont
définies voie par voie (et même selon le sens de circulation), cela n'a pas
beaucoup de sens de délimiter des zones et il est plus simple de définir
directement le "maxspeed=*" sur les voies elles-mêmes. Si on conserve ces
relations, je verrais d'un bon oeil le changement du tag en quelque chose
de plus clair ("boundary=restriction"+"maxspeed=*").




Le mer. 12 févr. 2020 à 19:20,  a écrit :

> Le 12/02/2020 à 18:02, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> place=municipality est dans un tableau "administratively declared places",
> ce qui va très bien avec nos communes nouvelles rurales. Il est par contre
> très peu utilisé: quelques milliers à peine sur le monde entier !
>
> On ne va pas non plus en ajouter des milliers
> 
> (713).
>
> La troisième règle non écrite d'OSM: toujours, toujours relire le wiki ;)
>
> Relire la bonne page du wiki, car il arrive qu'on trouve des infos pas à
> jour, incomplètes (traduction françaises pas à jour) ou incohérentes avec
> d'autres pages toujours sur le wiki.
>
> Je suis pour mettre des place=municipality avec les populations qui vont
> bien sur les communes nouvelles.
>
> Je maintiens que mettre la population sur l'admin_centre c'est ambigu dans
> le cas où la commune (municipality) n'est pas uniquement urbaine : est-ce
> celle du town/village ou celles additionnées des town/village/hamlet... ?
>
> Maintenant on peut décider qu'en France :
>
> -soit les population=* ne sont mis que sur les admin_centre/label des
> communes (niveau 8 ou aussi niveau 9 ?).
> - soit que les population=* qui sont mis sur admin_centre/label des
> communes (niveau 8 ou aussi niveau 9 ?) sont ceux de l'INSEE pour la
> commune et que les éventuels autres sont des informations autres qui ne
> s'ajoutent pas au total (et donc on met place=municipality pour lever
> l'ambiguïté ? Bof, c'est bien de savoir si le bourg est un town ou un
> village). Mais alors, pourquoi avoir enlevé INSEE= sur ces nœuds ?
> - autre ?
>
> Dans le cas d'une commune nouvelle où on met place=municipality sur un
> label, pas de 

Re: [OSM-talk] Forests are mappable - was: Re: OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Yves]

While I second Mateusz, the obvious solution for data users who may want to get 
rid of them in OSM is to filter them out.
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Diversity-talk] First Meeting of Diversity and Inclusion Special Committee

[Heather Leson]

Hey wonderful.

Sory to miss. Am away for a large work thing. Where are the items that need
help in between meetings?


Heather

On Wed, 12 Feb 2020, 21:13 Mikel Maron,  wrote:

> We just concluded second of two meetings today. Lots to digest, thanks to
> those who were able to make it. Raw notes are at
> https://hackmd.io/3cy5P9fhSvSVI8gkIHIX6w?view. My next action is to
> digest a bit, and create a page on the OSMF wiki with some things that came
> out of the meeting.
>
> Other next steps. Maggie is going to start a OSM wiki page to gather
> previous research, Rory is looking at tweaks to the Diversity Statement,
> and Jinal is putting together a short form to gather details on interest
> from people who didn't make this meeting.
>
> -Mikel
>
> * Mikel Maron * +14152835207 @mikel s:mikelmaron
>
>
> On Thursday, February 6, 2020, 01:41:45 PM EST, Mikel Maron <
> mikel.ma...@gmail.com> wrote:
>
>
> Last month, the OSMF adopted this Diversity Statement [1] and appointed a
> committee [2] to compile research and undertake new research on our
> diversity, identify root causes that contribute to any shortfalls, and make
> recommendations to help resolve issues and improve.
>
> If you're interested to take part, join an upcoming initial meeting of the
> committee. We're holding a first meeting on Wednesday February 12 at 1400
> UTC [3] on Mumble [4] (in the public OSMF Board of Directors room). Please
> join if you'd like to contribute. If you're unavailable at that time, let
> us know other times that might work, and we can schedule another kickoff
> meeting in addition.
>
> [1] https://wiki.osmfoundation.org/wiki/Diversity_Statement
> [2] https://hackmd.io/ZG8x44H4Skq0CPkcrMTB6A?view
> [3] Timezone converter:
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=DISC+Meeting=20200212T14=1440
> [4] How to use Mumble: https://wiki.openstreetmap.org/wiki/Mumble
>
> -Mikel
>
>
> ___
> Diversity-talk mailing list
> Code of Conduct:
> https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
> Contact the mods (private): diversity-talk-ow...@openstreetmap.org
>
___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

[OSM-talk] Forests are mappable - was: Re: OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Mateusz Konieczny via talk]

Feb 12, 2020, 01:54 by pierz...@yahoo.fr:

> > > > pierz...@yahoo.fr
> > > If we could keep the wood landcover outside of OSM, it would greatly 
> > > simplify mapping of such areas and dramatically reduce the Mulipolygons 
> > > problems where huge multipolygons are created with inner for lakes and 
> > > all the problems related to this.
>
> On Feb 11  18 h 49 min 26 s UTC−5, Mateusz Konieczny via talk wrote:
> >  ??? just do not create unreasonably large multipolygons (or split 
> >existing, 
> > possibly undo import if it makes area uneditable and do it right).
>
> Your answer seems to be that it is possible to map appropriately with the 
> current rules. Or maybe not, but anyway, let simply ignore these areas, not 
> find appropriate solution to add these areas  to OSM. For north of Canada 
> alone, > the superficy is closed to the size of Europe> .
>
I am pretty sure that it is possible to map forests in OSM. Can you link area 
where forests are somehow
not mappable and cause you to propose deleting tree coverage data from OSM?

You claimed that we should consider deleting tree coverage data from OSM and 
create a separate project
of it (what is mostly offtopic in this thread).

I responded that forests are mappable in OSM.
And poor data quality in an unspecific location is not a good reason to do 
something like that.

Why proposing solution for the problem would be ignoring it?

Hard to say more or verify without getting specific location but I cleaned up 
some places
mangled by badly done forest imports - for example border area that was hit 
with multiple
low quality imports.

But it sounds exactly like https://www.openstreetmap.org/user/Abbe98/diary/28368
that was solved by splitting unreasonably large relation in parts (by deleting 
it
and remapping)

And yes Canada is large and we may never finish mapping forests. It does not 
mean that
we should delete all forest data.

We will also never finish mapping shops, opening hours and many other things.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[osm . sanspourriel]

Le 12/02/2020 à 18:02, Christian Quest - cqu...@openstreetmap.fr a écrit :


place=municipality est dans un tableau "administratively declared
places", ce qui va très bien avec nos communes nouvelles rurales. Il
est par contre très peu utilisé: quelques milliers à peine sur le
monde entier !

On ne va pas non plus en ajouter des milliers

(713).

La troisième règle non écrite d'OSM: toujours, toujours relire le wiki ;)


Relire la bonne page du wiki, car il arrive qu'on trouve des infos pas à
jour, incomplètes (traduction françaises pas à jour) ou incohérentes
avec d'autres pages toujours sur le wiki.

Je suis pour mettre des place=municipality avec les populations qui vont
bien sur les communes nouvelles.

Je maintiens que mettre la population sur l'admin_centre c'est ambigu
dans le cas où la commune (municipality) n'est pas uniquement urbaine :
est-ce celle du town/village ou celles additionnées des
town/village/hamlet... ?

Maintenant on peut décider qu'en France :

-soit les population=* ne sont mis que sur les admin_centre/label des
communes (niveau 8 ou aussi niveau 9 ?).
- soit que les population=* qui sont mis sur admin_centre/label des
communes (niveau 8 ou aussi niveau 9 ?) sont ceux de l'INSEE pour la
commune et que les éventuels autres sont des informations autres qui ne
s'ajoutent pas au total (et donc on met place=municipality pour lever
l'ambiguïté ? Bof, c'est bien de savoir si le bourg est un town ou un
village). Mais alors, pourquoi avoir enlevé INSEE= sur ces nœuds ?
- autre ?

Dans le cas d'une commune nouvelle où on met place=municipality sur un
label, pas de soucis.

Jean-Yvon

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

Re: [Diversity-talk] First Meeting of Diversity and Inclusion Special Committee

[Mikel Maron]

We just concluded second of two meetings today. Lots to digest, thanks to those 
who were able to make it. Raw notes are at 
https://hackmd.io/3cy5P9fhSvSVI8gkIHIX6w?view. My next action is to digest a 
bit, and create a page on the OSMF wiki with some things that came out of the 
meeting.
Other next steps. Maggie is going to start a OSM wiki page to gather previous 
research, Rory is looking at tweaks to the Diversity Statement, and Jinal is 
putting together a short form to gather details on interest from people who 
didn't make this meeting.
-Mikel
* Mikel Maron * +14152835207 @mikel s:mikelmaron 

On Thursday, February 6, 2020, 01:41:45 PM EST, Mikel Maron 
 wrote:  
 
  Last month, the OSMF adopted this Diversity Statement [1] and appointed a 
committee [2] to compile research and undertake new research on our diversity, 
identify root causes that contribute to any shortfalls, and make 
recommendations to help resolve issues and improve. 
If you're interested to take part, join an upcoming initial meeting of the 
committee. We're holding a first meeting on Wednesday February 12 at 1400 UTC 
[3] on Mumble [4] (in the public OSMF Board of Directors room). Please join if 
you'd like to contribute. If you're unavailable at that time, let us know other 
times that might work, and we can schedule another kickoff meeting in addition.
[1] https://wiki.osmfoundation.org/wiki/Diversity_Statement[2] 
https://hackmd.io/ZG8x44H4Skq0CPkcrMTB6A?view[3] Timezone converter: 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=DISC+Meeting=20200212T14=1440[4]
 How to use Mumble: https://wiki.openstreetmap.org/wiki/Mumble
-Mikel

  ___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [Talk-it] vie ferrate e vie di arrampicata

[liste DOT girarsi AT posteo DOT eu]

Il 12/02/20 10:55, Alfredo Gattai ha scritto:
> Lo scopo e' quello di distinguere nettemente una via ferrata da un percorso
> definito escursionistico.
> Se un percorso ha al suo interno un breve tratto attrezzato con difficolta'
> che non ecceda EEA:F potra' rimanere come route=hikibg e la sua
> cai_scale=EEA:F.
> I singoli tratti avranno il loro sac_scale e le loro caratteristiche.
> 
> Quando invece la difficolta' aumenta ed il percorso diventa una via ferrata
> allora va definito come tale.
> La ragione di fare una relazione invece della singola way sta nel fatto che
> anche le ferrate spesso hanno tratti di collegamento che magari sono
> semplici path percio' per collegare il tutto l'opzione migliore sembra
> essere la relazione.
> 
> All'inizio di Marzo avremo in sede centrale una conversazione sulle scale
> di difficolta' e sula distinzione fra sentiero attrezzato e via ferrata. A
> valle di cio' poi potremo andare avanti con la definizione della mappatura.
> 
> Una volta raggiunto un minimo di standardizzazione postero' sul github di
> waymarkedtrails una richiesta di localizzazione con delle proposte di
> rendering in modo da dare un minimo di chiarezza su cosa e' cosa quando si
> guarda la mappa.
> 
> Alfredo

Grazie per la spiegazione, ma mi resta il dubbio numero sentiero, cioè
se la ferrata è parte del sentiero, e quindi un unicum ma che la stessa
definisce la massima difficoltà per forza di cose, e quindi su OSM fa
riferimento il tag cai_scale=* e diventa un'unica relazione con i tag
specifici della ferrata rilasciati sui tratti interessati, e i tratti di
sentieri tra eventuali ferrate coi rispettivi tag dedicati.

Quindi mi chiedo e ti chiedo, si sta revisionando l'intero catasto CAI
in modo da definire separatamente sentiero e ferrata, coi numeri
sentieri ben separati in modo da avere ben distinti i tratti numerati
sitematicamente?

Per SAT non so, al momento non vedo differenze dall'attuale catasto, su
OSM, ma mi pare evidente che se si fa a livello nazionale
inevitabilmente si a a livello regionale.


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

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

Re: [Talk-it] centro riparazione elettrodomestici

[liste DOT girarsi AT posteo DOT eu]

Il 12/02/20 17:51, demon_box ha scritto:
> ...e non invece (trattandosi di elettrodomestici)
> 
> craft=appliances_repair ?
> 

C'è un futures messo come obsoleto che propone:

craft=electronics_repair

electronics_repair=appliance


Non so se è riproponibile per votazione, perchè bisogna poi dare
spiegazioni e approfondimenti.


https://wiki.openstreetmap.org/wiki/Proposed_features/craft%3Delectronics_repair
-- 
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Christian Quest]

Le 12/02/2020 à 17:04, Rpnpif via Talk-fr a écrit :
Merci d'avoir pris en compte ce problème et merci pour vos suggestions 
(place=municipality) qui me font réfléchir..


Le problème est assez peu différent pour les communes anciennes et non 
fusionnées récemment ayant plusieurs agglomérations séparées. 
L'admin-centre n'est pas forcément l'agglomération la plus grande mais 
celle où est se situe le bâtiment de la mairie et on y met un place=* 
(Oui, Florimond, j'ai bien compris tes griefs et exemples).


J'aurais une suggestion qui va peut-être choquer : ce serait de 
remplacer place=village/town des anciennes communes incluses dans la 
fusion par des place=quarter/neighborough et de placer le nom de la 
nouvelle commune sur l'admin-centre en place=village/town/city comme 
on le fait pour Nantes, Paris, etc. toutes issues de fusions plus ou 
moins anciennes (oui bon la différence, c'est que ces communes ont 
gardé le nom de la commune principale).


Parce que, à priori, les communes dites déléguées ne sont que de 
futurs arrondissements ou quartiers de la nouvelle. Aujourd'hui, ce 
sont des sortes de quartiers à statut spécial.


Il me semble qu'on peut parler de quartiers quand c'est un sous ensemble 
d'une agglomération (fusion ou pas), mais pour le cas de la majorité des 
communes nouvelles, on est en zone rurale et on a des bourgs séparés, 
isolés les uns des autres.


Vu du terrain, ce sont des villages, qui oui, sont regroupés 
(uniquement) administrativement, mais on ne peut pas les considérer 
comme des quartiers.


Je m'appuie sur mon expérience locale autour de mon point de chute 
bourguignon avec plusieurs communes nouvelles à proximité. Si je 
demandais aux habitants leur point de vue, je doute fort qu'un seul se 
considère comme habitant d'un quartier de la commune nouvelle.


De même, ma commune point de chute (non fusionnée) se compose en fait de 
7 hameaux... et pas de quartiers non plus.


Petit tour sur https://wiki.openstreetmap.org/wiki/Key:place pour se 
remettre la logique de place=* en tête...


Le wiki est plutôt clair avec 4 tableaux... quarter et neighbourhood 
sont des parties de suburb qui est lui même une partie de city/town, 
donc de grosses agglomérations. C'est d'ailleurs uniquement dans un 
tableau "urban".


Pour le tableau "rural", on a town, village, hamlet, isolated_dwelling, 
farm, allotments... et rien d'autre ce qui me semble logique et lié à la 
population (le retour) qui se trouve sur ces place=*.


place=municipality est dans un tableau "administratively declared 
places", ce qui va très bien avec nos communes nouvelles rurales. Il est 
par contre très peu utilisé: quelques milliers à peine sur le monde entier !


La troisième règle non écrite d'OSM: toujours, toujours relire le wiki ;)

--
Christian Quest - OpenStreetMap France


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

Re: [Talk-it] centro riparazione elettrodomestici

[demon_box]

...e non invece (trattandosi di elettrodomestici)

craft=appliances_repair ?

--enrico



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

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

Re: [Talk-it] centro riparazione elettrodomestici

[liste DOT girarsi AT posteo DOT eu]

Il 12/02/20 17:33, demon_box ha scritto:
> ciao, come da oggetto, qual'è il tag corretto per un centro che ripara
> elettrodomestici?
> grazie
> 

forse questo:

https://wiki.openstreetmap.org/wiki/IT:Tag:craft%3Delectronics_repair


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

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

[Talk-it] centro riparazione elettrodomestici

[demon_box]

ciao, come da oggetto, qual'è il tag corretto per un centro che ripara
elettrodomestici?
grazie

--enrico




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

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

Re: [OSM-talk-fr] Structures de soins en addictologie (CSAPA, CAARUD…)

[Rpnpif via Talk-fr]

Réponse rapide.

Le 12/02/2020 à 11:01, Yves P. a écrit :

Bonjour,

[...]
*Faut-il nettoyer les données OSM ?*
Une recherche (NOMINATIM) avec le terme CSAPA 
 renvoi 
« Clinique », « Hospital », « Service social » , « Salle polyvalente ».


Une recherche Overpass avec "social_facility:for"=drug_addicted en 
France  montre que les tags 
amenity=social_facility et social_facility=* ne sont pas toujours 
présents.
Je dirais plutôt proposer une règle Osmose au lieu d'une modification 
massive.


--
Rpnpif


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

[OSRM-talk] Matching behaviour for split parameter

[André Siefken]

Hi folks,

I run an application where both large collections and incremental
additions need to be matched. This is an intermediate step in a more
complex processing, and requires consistent output (except, of course,
the input GPS point sequence is completely bogus, which /should/ be
acounted for prior to feeding into OSRM).

By default, the Matching service is free to split the trace into
sub-traces based on large gaps, resulting in more than one *Route*
object in the *matchings* object. Correct me please if this is not
exactly the behaviour,and there may be other reasons for more than one
*Route* object.

  * Q: What exactly happens if I deny the splitting; does the whole
trace get a 'No Match' if it otherwise would get split?
  * Q: If yes, would the whole request get a 'No Match' even with
splitting allowed, in a case where it cannot find matches for a
subset of points?
  * Q: And if not, how does OSRM fill in theses gaps?

As a follow up: to get consistent results, I intend to implement a
fallback where I try to Route instead between the last '0
alternatives_count' waypoint and the first of two consecutive
sub-traces, to at least have /some/ output to proceed with.

  * Q: does that make sense in the case the /do-not-split/ setting would
otherwise produce a 'No Match' for the whole trace?


Many thanks in advance,

André

-- 

pgp-key attached



0x0024705C4FC20AF6.asc
Description: application/pgp-keys
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Rpnpif via Talk-fr]

Merci d'avoir pris en compte ce problème et merci pour vos suggestions 
(place=municipality) qui me font réfléchir..


Le problème est assez peu différent pour les communes anciennes et non 
fusionnées récemment ayant plusieurs agglomérations séparées. 
L'admin-centre n'est pas forcément l'agglomération la plus grande mais 
celle où est se situe le bâtiment de la mairie et on y met un place=* 
(Oui, Florimond, j'ai bien compris tes griefs et exemples).


J'aurais une suggestion qui va peut-être choquer : ce serait de 
remplacer place=village/town des anciennes communes incluses dans la 
fusion par des place=quarter/neighborough et de placer le nom de la 
nouvelle commune sur l'admin-centre en place=village/town/city comme on 
le fait pour Nantes, Paris, etc. toutes issues de fusions plus ou moins 
anciennes (oui bon la différence, c'est que ces communes ont gardé le 
nom de la commune principale).


Parce que, à priori, les communes dites déléguées ne sont que de futurs 
arrondissements ou quartiers de la nouvelle. Aujourd'hui, ce sont des 
sortes de quartiers à statut spécial.


--
Rpnpif

Le 11/02/2020 à 18:03, Christian Quest a écrit :

Prenons un exemple pour réfléchir:

- Montholon (commune nouvelle): place=municipality + population=1500

  - Aillant-sur-Tholon (commune chef-lieu): place=village + 
population=1000


  - Volgré (commune déléguée): place=village + population=300

  - Villiers-sur-Tholon (commune déléguée): place=village + 
population=200


Chaque noeud est admin_centre d'une relation admin_level=8 ou 9


Sur le rendu, Montholon sera placé en priorité, puis Aillant, puis 
Volgré, puis Villiers.


Comme on aura plus le détail des populations des communes déléguées 
(quoique*) on peut conserver ce qu'on a de plus récent et on a le 
millésime en source:population


De toute façon, quelqu'un qui aurait besoin des populations à jour 
ferait quand même bien mieux (en France) de prendre le fichier de 
l'INSEE ;)



Place sur la relation + sur le noeud ? Bof bof bof, ça ne me semble 
pas cohérent car on a un doublon de place=* (qui décrit un objet, 
contrairement à population=* qui n'est pas un "objet" en tant que tel 
mais un attribut d'un objet).



* avec le carroyage INSEE on pourrait très bien déduire 
approximativement la population d'un hameau, d'un écart, etc...





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

[OSM-talk] Clarify explicit abstention when voting on a proposal

[Daniel Capilla]

Hi,

There is an ongoing discussion to clarify if whatever explicit 
abstaining is the same as no vote during the process of approving a 
proposal. [1] Please feel free to participate in the discussion.


I'll send another message to the tagging mailing list.

Happy mapping.

Regards,

Daniel


[1] 
https://wiki.openstreetmap.org/wiki/Talk:Proposal_process#Clarify_whatever_explicit_abstaining_is_the_same_as_no_vote



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

Re: [Talk-hr] Krivi editi

[Matija Nalis]

slobodno daj ti

On Wed, Feb 12, 2020 at 11:41:36AM +0100, Janko Mihelić wrote:
> Jel kontantiran? Mogu ja ako još nitko nije.
> 
> uto, 11. velj 2020. u 03:57 Matija Nalis <
> mnalis-openstreetmapl...@voyager.hr> napisao je:
> 
> > da, idealno bi bilo kontaktirati autora, i vidjeti zasto to prepravlja?
> >
> > On Mon, Feb 10, 2020 at 11:42:26AM +0100, Ivan Habunek wrote:
> > > Bok ekipa,
> > >
> > > Uočio sam na OSM Inspektoru da su krivo tagana stajališta autobusa u
> > Velikoj gorici.
> > >
> > > Pogledao sam povijest i ispada da ih je Janjko ispravno unio kao
> > public_transport=platform ali onda je fran_B prepravio u
> > platform=stop_position, što je neispravno.
> > >
> > > Što se radi u ovakvoj situaciji? Kako se reverta? Trebamo kontaktirati
> > autora i pričati s njime? :)
> > >
> > > Inspektor:
> > https://tools.geofabrik.de/osmi/?view=pubtrans_stops=16.07700=45.71120=18=stops_,stops_positions,stops_classic,stops_positions_not_on_ways,platforms_,platforms_nodes,platforms_ways
> > >
> > > Changeset: https://www.openstreetmap.org/changeset/80529745
> > >
> > > History jednog od nodeova:
> > http://osm.mapki.com/history/node.php?id=7038174257
> > >
> > > Pozdrav,
> > > -- Ivan
> > >
> > > ___
> > > Talk-hr mailing list
> > > Talk-hr@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-hr
> >
> > --
> > Opinions above are GNU-copylefted.
> >
> > ___
> > Talk-hr mailing list
> > Talk-hr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-hr
> >
> ___
> Talk-hr mailing list
> Talk-hr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-hr

-- 
Opinions above are GNU-copylefted.

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

Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

[Stéphane Péneau]

Le 12/02/2020 à 13:31, Charles MILLET a écrit :


Je ne suis pas à l'aise avec l'idée de faire un signalement au DWG 
car en dehos de ce genre de comportement, ses contributions sont 
bonnes. Pensez-vous qu'il faille le faire ?



Oui, mais j'ai un point de vue biaisé puisque partie prenante.

Stf


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

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-12 10:42, Frederik Ramm wrote:

> Hi,
> 
> On 2020-02-12 10:28, Colin Smale wrote: 
> 
>> Where a boundary coincides with the centre line of
>> a road for example, and there is a discrepancy in OSM between the
>> locations of the two, there should be a recognition that the
>> professionally surveyed locations are more likely to be correct
> 
> I disagree.
> 
> What you are requesting here is that we blindly defer to authorities. "I
> cannot verify this - but a professional surveyor with his $10k equipment
> claims it is so - hence I guess I have to believe it."

Indeed, that is exactly what I am suggesting (without the "blindly"
bit). You can verify it, just not there and then with your cheap GPS.
OSM is built on trust, not mistrust. 

> I think this is not how OpenStreetMap should be operating. I can see how
> to a professional surveyor the idea must be painful that someone comes
> along with their rubbish equipment and makes a change, but we *are* a
> project of hobbyists and volunteers, and something that a hobbyist and
> volunteer cannot verify ("don't touch this unless you invest $10k in
> equipment first!!!") should not be in OSM, and we should not worship
> precision that we cannot create ourselves.

Exactly this. A hobbyist or volunteer CAN verify an admin boundary
(where it is available as open data) - it is independently verifiable.
It is objectively of better quality than an OTG observation with a
phone. 

The professional surveyor probably couldn't care less. I am thinking of
our downstream consumers.  Sounds a bit like Brexit... 

But some awareness amongst these hobbyists that some sources are better
than others, and their own measurements, even if they are more recent
than the contents of OSM, are not necessarily better, would surely not
be a bad thing.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Mikel Maron]

Colin doesn’t seem to be advocating for deference to and worship of authorities 
in all situations. That’s an over the top interpretation. 
It’s maybe better to say that it’s something to consider when evaluating data — 
as we always look at a mappers context in OSM when looking at edits and 
revisions.
Side point
>  we *are* a project of hobbyists and volunteers
and professionals. And students and researchers. And anyone else who wants to 
participate in an open map. Been that way since the beginning.
Let’s not cut ourselves short in comparison to “professional” tools. Many of 
the software tools we’ve developed as a community are leading the industry. 

Mikel

On Wednesday, February 12, 2020, 4:42 AM, Frederik Ramm  
wrote:

Hi,

On 2020-02-12 10:28, Colin Smale wrote:
> Where a boundary coincides with the centre line of
> a road for example, and there is a discrepancy in OSM between the
> locations of the two, there should be a recognition that the
> professionally surveyed locations are more likely to be correct

I disagree.

What you are requesting here is that we blindly defer to authorities. "I
cannot verify this - but a professional surveyor with his $10k equipment
claims it is so - hence I guess I have to believe it."

I think this is not how OpenStreetMap should be operating. I can see how
to a professional surveyor the idea must be painful that someone comes
along with their rubbish equipment and makes a change, but we *are* a
project of hobbyists and volunteers, and something that a hobbyist and
volunteer cannot verify ("don't touch this unless you invest $10k in
equipment first!!!") should not be in OSM, and we should not worship
precision that we cannot create ourselves.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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



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

Re: [Talk-GB] Freemap (free-map.org.uk) - potential shutdown

[Richard Fairhurst]

Nick Whitelegg wrote:
> I am proposing shutting down my (very old) England and 
> Wales footpath mapping site Freemap (free-map.org.uk).

Wow, there's a blast from the past!

Freemap was of course one of the very first grassroots mapping sites (2004),
together with my geowiki.com (2003 [1]), Jo and Schuyler's freemap.in
(2005?), and OpenStreetMap itself (2004).

We all converged on OSM sooner or later, but it's a worthwhile historical
detail to remember the early days.

Richard

[1] http://www.systemed.net/blog/legacy/entry071107122332.html



--
Sent from: http://gis.19327.n8.nabble.com/Great-Britain-f5372682.html

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

Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

[Charles MILLET]

Pardon, mauvais lien, voilà le bon :

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

On 12/02/2020 13:24, Charles MILLET wrote:

Bonjour à tous,

Voilà donc, sans surprise, Meersbrook a supprimé le chemin qui était 
en question et en a profiter pour en supprimer d'autres. Pour c'est 
clairement de la malveillance et une forme de vengeance. Aucune 
discussion sur ces suppressions.


Voilà le changeset en question : 
https://www.openstreetmap.org/changeset/80698774


Je ne suis pas à l'aise avec l'idée de faire un signalement au DWG car 
en dehos de ce genre de comportement, ses contributions sont bonnes. 
Pensez-vous qu'il faille le faire ? Je serais également favorable à un 
revert sur ce changeset, qu'en pensez vous ?


Charles.

On 07/02/2020 15:49, Charles MILLET wrote:

Bonjour à tous

J'ai à nouveau un problème de conflit d'édition avec l'utilisateur 
Meersbrook. cf. https://www.openstreetmap.org/changeset/79878637


En résumé il a supprimé l'ajout d'une piste cyclable (discutable mais 
ce n'est pas le sujet) pour la remplacer par un track. Ce sujet a 
déjà été discuté avec lui pour des pratique identique à Caen et je 
suppose qu'il le fait malheureusement régulièrement. Je suis à la 
recherche des discussions à ce sujet pour reprendre les arguments.


Pour info cette "piste cyclable" est utilisable par les piétons et 
donc nécessite un way séparé et la précision du segregated=yes


Je suis à la recherche d'un peu d'arbitrage car mes échanges avec 
Meersbrook sont insupportables et totalement non constructif à cause 
de son ton ultra arrogant et différents reproches totalement délirant.


Charles


___
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: [Talk-se] Malmö och Örnsköldsvik saknas på vektorkarta

[pangoSE]

On 2020-02-08 13:13, Essin wrote:

Hej!

PangoSE, kan du till att börja med be SCB att uppdatera sin hemsida? För 
närvarande står det visserligen att tätortsgeometrierna är öppna data 
[1] men också att deras öppna data är CC-BY-licensierade [2] vilket inte 
är tillräckligt för OSM [3]. Det är ingen bra idé att ladda upp data med 
oklar licens.


Som jag skrev i min epost:
"LM har släppt alla tätortspolygoner som CC0 så det är bara att importera.
(Se geojson fil här https://www.mediafire.com/folder/dzngn1k5y2xjq/)"




Tätortsavgränsningarna ritas om från grunden vart tredje år. Vem tar 
ansvar för att det hålls uppdaterat någon längre tid? Vi har fortfarande 
kvar mera begränsade tätortsuppgifter som blev inaktuella 2015, t ex 
[4], och eftersom ändringar i tätortsindelningen inte är direkt 
observerbara på marken kan det dröja länge innan någon märker att något 
är fel, om det inte kontrolleras systematiskt. Ett liknande fall är 
naturreservaten, som importerades runt 2010. Jag har under en längre tid 
sysslat med att gå igenom naturreservaten för att slå ihop överlappande 
gränser, och där finns det många fall av gränsförändringar och nyskapade 
reservat som inte har uppdaterats trots att naturreservaten har mer 
stabila gränser än tätorterna.


Va bra! Jag är medveten om att detta är ett stort jobb. Jag föreslår att 
vi automatiserar det som jag skrivit tidigare.




Tätortsavgränsningarna har ingen som helst administrativ funktion och 
det är därmed direkt fel att tagga dem som boundary=administrative. 
Tätbebyggda områden (som kommunerna använder för att avgränsa t ex 
50-begränsningar och tomgångskörningsförbud) har en viss administrativ 
funktion och är indirekt observerbara på marken genom vägskyltar när man 
passerar deras gränser, men det är en annan sak. Möjligtvis skulle 
boundary=census [5] fungera för tätortsavgränsningarna, om de trots alla 
invändningar ska finnas i OSM.




Jag blir ännu mer skeptisk när jag ser hur tätortsavgränsningarna har 
lagts in hittills, som i Malmö [6]. Relationen har note=Tätortsgränsen 
följer inte LMs polygon slaviskt eftersom att denna inte täckte alla 
områden ordentligt. Vad är överhuvudtaget meningen med att rita ut 
tätortsgränser separat på OSM om det inte är de av SCB definierade 
tätorterna? Den dataanvändare som vill använda OSM-data för att få en 
uppfattning om bebyggda områden får ett bättre resultat av att aggregera 
urbana markanvändningstyper som landuse=residential, industrial, retail 
etc, eller i välmappade områden (som Malmö!) genom att analysera building=*.



Jag gillar ditt argument här. Jag la första gång in en 
boundary=administrative när det behövdes för att få 
https://maposmatic.osm-baustelle.de/ att funka som tänkt för svenska 
tätorter. Detta kan ju uppfattas som tagging for the renderer vilket jag 
inte är tillhängare av.
Det går bra för mig att vi ändrar till =census och jag håller med om att 
vi då bör bevara polygonformerna som dem kommer från LM (eller SCB om 
nån lyckas övertycka chefledet om det tokiga med valet CC-BY, se 
https://se.wikimedia.org/wiki/%C3%84mne:Vavz1c9h6p2kc1l5)


Tyvärr innebär detta att maposmatic/myosmatic inte kommer ha med alla 
vägar inom tätorten Malmö som jag som användare skulle förvänta mig om 
jag söker på Malmö och gör en karta över denna stad. Det innebär att 
verktyget kanske måste ändras till att göra den analys du föreslår för 
att själv hitta avgränsningar för tätorter via en algoritm.


Det finns f.ö. över en miljon place=city som är ritad som area i 
databasen, hur ställer du dig till place= på områden?


Mvh
pangoSE



Den tors 23 jan. 2020 kl 14:39 skrev pangoSE >:


Hej.

Jag tycker att vi skal tolka tätortsområden som administrativa
gränser för våra städer. Det är den bästa källa vi har, alternativet
är att göra dem subjektivt själva som jag ser det.

Det är korrekt att dem uppdateras av SCB vart 5-e år. SCB har dock
bara släppt dem som CC-BY varför jag föreslår att vi tar dem från
LM. Jag ser inte det som ett problem att gränserna uppdateras när
byn byggs ut eller stadsdelar rivs.

Dem används inte bara av rendere också av tex
https://maposmatic.osm-baustelle.de
 där det inte i dagsläget går
att göra en karta över tex Malmö av skälet att staden inte är
definerad som område.

Se skillnaden när du söker här på härnösand vs malmö:
https://maposmatic.osm-baustelle.de/new/#

Vi saknar altså vettiga admin boundaries på våra städer. Alla
svenska städer jag testade utom Härnösand och Umeå kunde inte lätt
hittas.

När man skapar bykartor då är det vettigt att bara ta med gatunamn
inom byområdet och detta gör verktyget om vi har definerad gränserna.

Jag skapade precis denna cykelkarta för Umeå med alla gatunamn i en
bilaga där området utanför tätorten är grått och gator som ligger
utanför byområdet inte tas med i indexet, se:

Re: [OSM-talk-fr] ref et ref:FR

[leni]

Le 12/02/2020 à 00:33, marc marc a écrit :

on ets en plein dogme,
Il me semble que c'est plutôt un état de l'existant (il me semblait que 
tu avais dit qu'il était difficile de retrouver les ref:FR: ...)

  cfr Réseau Arc en ciel de bus en france
Que t'a-t-il fait ? il me semble qu'il n'a rien inventé, il n'a fait que 
ce qui est dans le wiki ; et je n'ai pas encore d'avis sur l’intérêt de 
ta solution (pour les transport en commun) est-elle mieux ? peut-être ? 
mais elle me parait ne pas être assez avancée pour être appliquée. 
Lorsqu'elle pourra régler tous les cas, on verra.


Car, Il n'y a pas que des arrêts communs que entre régional et local, et 
je ne sais pas où est BATO.


Voir https://transport.data.gouv.fr/ : Je n'ai pas tout analysé dans les 
gtfs, mais on a des n° d'arrêts différents pour chaque réseau.


On aura des arrêts communs pour les réseaux longue distance ; exemple 
avec la Gare routière de Toulouse qui voit les réseaux longue distance 
et régionaux :


Flixbus :
FLIXBUS:4878,,Toulouse,"68 - 70 Boulevard Pierre Semard, 31500 Toulouse, 
France",43.612522,1.452612,,,0,,Europe/Paris,2,


Eurolines :
NB:Stop:2596,Toulouse Gare Routière,,43.6126,1.452641,NB:Zone:2596,0,

Ouibus :
XTS,,Toulouse,,43.61329878,1.452226002,Europe/Paris,1

Arc-en-Ciel (Réseau régional en Haute-Garonne liO31) :
STOPPOINT:02001,61103,TOULOUSE - Gare 
Routière,,43.612939,1.452511,,,0,STOPAREA:02001,,1


Réseau régional en Ariège liO09 :
S03228,,"TOULOUSE - GARE ROUTIERE","",43.613276,1.452145,,,1,,,

On aura des arrêts communs à l'intérieur d'une même région entre deux 
départements d'un réseaux régional  (comme ci-dessus)


Entre régions différentes

Entre réseau régional scolaire et réseau régional lignes régulières

entre réseau régional lignes régulières et réseau de regroupement de 
communes


entre réseau régional scolaire et réseau de regroupement de communes

entre réseau regroupement de communes et communal

et j'en oublie ...


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

Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

[Charles MILLET]

Bonjour à tous,

Voilà donc, sans surprise, Meersbrook a supprimé le chemin qui était en 
question et en a profiter pour en supprimer d'autres. Pour c'est 
clairement de la malveillance et une forme de vengeance. Aucune 
discussion sur ces suppressions.


Voilà le changeset en question : 
https://www.openstreetmap.org/changeset/80698774


Je ne suis pas à l'aise avec l'idée de faire un signalement au DWG car 
en dehos de ce genre de comportement, ses contributions sont bonnes. 
Pensez-vous qu'il faille le faire ? Je serais également favorable à un 
revert sur ce changeset, qu'en pensez vous ?


Charles.

On 07/02/2020 15:49, Charles MILLET wrote:

Bonjour à tous

J'ai à nouveau un problème de conflit d'édition avec l'utilisateur 
Meersbrook. cf. https://www.openstreetmap.org/changeset/79878637


En résumé il a supprimé l'ajout d'une piste cyclable (discutable mais 
ce n'est pas le sujet) pour la remplacer par un track. Ce sujet a déjà 
été discuté avec lui pour des pratique identique à Caen et je suppose 
qu'il le fait malheureusement régulièrement. Je suis à la recherche 
des discussions à ce sujet pour reprendre les arguments.


Pour info cette "piste cyclable" est utilisable par les piétons et 
donc nécessite un way séparé et la précision du segregated=yes


Je suis à la recherche d'un peu d'arbitrage car mes échanges avec 
Meersbrook sont insupportables et totalement non constructif à cause 
de son ton ultra arrogant et différents reproches totalement délirant.


Charles


___
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] ref et ref:FR

[leni]

Le 11/02/2020 à 23:47, François Lacombe a écrit :

Bonsoir à vous

+1 avec vous, bonne idée de séparer le tableau, pourquoi pas par 
thèmes, comme nous le faisons pour les Map Features ?
Sur le caractère national/local, pourquoi pas ajouter une colonne dans 
les tables pour le préciser ?
J'ai préparé un tableau avec lbo (plus facile à trier) avec une colonne 
(qui ressemble Map Features) et une national/local, je le mettrais ici 
quand j'aurais avancé




Sur le partage, que du bien. Et peut-être "l'ordonner" voire le
découper
par thème ?
Il me semble que j'en avais déjà parlé, sans grand succès...


désolé, ce devait être pendant une de mes absences



-- 
deuzeffe - qui n'a pas oublié la page transport à toiletter.



Il me semblait t'avoir répondu et modifié le chapitre Occitanie
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-ja] いたずら目的の POI?

[Talk-ja 経由]

こんにちは、奈良の石川です。

以下の POI 


https://www.openstreetmap.org/node/7003777889

について、「こんな場所に動物病院ができたのかな」と思い、本日たまたま近くを通ることがあったので現場にいってみましたが、自治会の集会所があるだけで動物病院などありませんでした。

そもそもこの POI について、

・日本国内の住宅街なのにベトナム語 (ベトナム料理店ならベトナム語でもおかしくないですが…)
・名称を Google 翻訳にかけると「トーアンの犬小屋」と出てくる
・同じ changeset には「」などというふざけた名称もある
・同じ changeset には「nhà tôi」(私の家) という POI がある
・この changese 自体、日本からベトナムにかけて広すぎる範囲である
・POI を作成した方はこの changeset しか編集していない

という状態です。いたずら目的かなぁ、と思うのですが、こういう場合、どのように対処するものでしょうか。(どなたか慣れている方が対処していただけると助かるのですが…。)

-- 
石川
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] ref et ref:FR

[François Lacombe]

Bonjour

Des arguments sont toujours attendus pour faire autrement.

3 points :
* Qui sommes-nous pour affirmer que le nom de la ref ne collisionnera pas
ailleurs ?

* Le namespace permet de spécialiser la ref, d'y associer une documentation
complète et de séparer les concepts.
En ce qui me concerne, toutes les ref crées selon ce motif sont documentées
et vous serez bien inspirés non seulement de proposer cette documentation
sur une clé unique et aussi d'aller les valider dans les éditeurs

* Dans des cas de multi-ref (plus souvent le cas qu'on ne le pense), on
distingue clairement les différents concepts en jeu.
Avoir ref=* + ref:autre n'est pas acceptable à plusieurs titres : on
perdrait l'info de ce qui est effectivement lu sur le terrain (qui peut
contenir plusieurs champs)
Exemple : https://www.openstreetmap.org/relation/6668144

J'ai reporté ces arguments sur le wiki
https://wiki.openstreetmap.org/wiki/Talk:France/Liste_des_r%C3%A9f%C3%A9rences_nationales#Arguments_pour.2Fcontre_le_recours_aux_namespaces_locaux

Qu'il y ait des références mal définies, c'est vrai et du temps est
nécessaire pour les reformuler
De là à parler de dogme, c'est pas le cas n'est-ce pas ?

Bonne journée

François

Le mer. 12 févr. 2020 à 00:34, marc marc  a
écrit :

> on ets en plein dogme, cfr Réseau Arc en ciel de bus en france
>
> Le 12.02.20 à 00:21, François Lacombe a écrit :
> > En corollaire à ces propositions, je pensais suggérer à l'international
> > de ne laisser sur la page ref que les références mondiales
> > J'ai déjà supprimé le peu de ref:FR qui s'y trouvaient, en laissant
> > évidemment les liens vers la page française des références nationales.
> >
> > Cela permettra de clarifier les choses entre mondial/national et
> > d'inciter les pays à créer leurs propres page et namespace
> >
> > Penser qu'il y a aussi un niveau continental, avec quelques entrées en
> > Europe par exemple
> > https://wiki.openstreetmap.org/wiki/FR:Key:ref:EU:EVSE
> > https://wiki.openstreetmap.org/wiki/Key:ref:EU:ENTSOE_EIC
> >
> > Bonne soirée
> >
> > François
> >
> > Le mar. 11 févr. 2020 à 23:47, François Lacombe
> > mailto:fl.infosrese...@gmail.com>> a écrit :
> >
> > Bonsoir à vous
> >
> > +1 avec vous, bonne idée de séparer le tableau, pourquoi pas par
> > thèmes, comme nous le faisons pour les Map Features ?
> > Sur le caractère national/local, pourquoi pas ajouter une colonne
> > dans les tables pour le préciser ?
> >
> > Globalement, tout ce qui favorise l'adoption de ref:FR:* est bon à
> > prendre.
> >
> > François
> >
> > Le mar. 11 févr. 2020 à 18:57, deuzeffe  > > a écrit :
> >
> > Hello,
> >
> > Le 11/02/2020 à 18:25, leni a écrit :
> > > Bonjour
> > >
> > > En attendant que nous trouvions une meilleure solution pour
> > certaines
> > > ref:FR:*** , je pense qu'il serait bien de partager le tableau
> > de la
> > > page
> > >
> >
> https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
> >
> > > (1) en deux parties :
> > > - une première partie avec les références qui s'appliquent sur
> > > l'ensemble du territoire (ref:FR:ARCEP=* ; ...) en y ajoutant
> > celles que
> > > j'ai trouvées dans le wiki (2)
> > > - une partie pour les autres (ref:FR:CRTA=*en Aquitaine ;
> > > ref:FR:BSPP:=* ; ref:FR:RATP=*) en y ajoutant celles que
> j'ai
> > > trouvées dans le wiki (3)
> > > - Faut-il y ajouter ref:FR:TransGironde et ref:FR:CUB qui sont
> > dans osm
> > > et que je n'ai pas trouvées dans le wiki ?
> > >
> > > Qu'en pensez-vous ?
> >
> > Sur le partage, que du bien. Et peut-être "l'ordonner" voire le
> > découper
> > par thème ?
> > Il me semble que j'en avais déjà parlé, sans grand succès...
> >
> > --
> > deuzeffe - qui n'a pas oublié la page transport à toiletter.
> >
> > ___
> > 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-se] Ortnamnsimport från Lantmäteriets GSD-Terrängkartan

[Grigory Rechistov via Talk-se]

 
Hej,
Om ni är intresserade följer Lantmäteriets svar på mitt ärende om avstavade 
ortnamn på GSD-terrängkartan.

 
Hej
 
Nu har jag fått svar från den kartingenjör som handlagt ditt ärende.
 
Tyvärr så saknas de fullständiga namnen (utan förkortningar och avstavningar) 
som attribut i våra produkter, utan endast den text som är anpassad för visning 
i kartan är med. Vi vet att det är en brist och i de nya produkterna som vi 
håller på att ta fram kommer både ”karttexten” och det fullständiga namnen 
finnas med.
Ingen åtgärd kommer att göras i den befintliga GSD-Terrängkartan, vektor. I den 
produkt som kommer att ersätta GSD-Terrängkartan (Preliminärt hösten 2021) 
kommer namnen att vara åtgärdade.
 
Vi avslutar nu ditt ärende.
 
Vänligen ange ärendenumret som står i rubriken om du vill kontakta oss igen i 
detta ärende.
 
 
Vänlig hälsning
 
 
Teresa 
Ärendekoordinator felanmälan
 
LANTMÄTERIET
E-POST felrapport.grunddataprod...@lm.se
TELEFON    026-63 33 36   
ADRESS    Lantmäteriet, 801 82 Gävle
WEBBPLATS    www.lantmateriet.se
 
www.linkedin.com/company/lantmateriet
www.facebook.com/lantmateriet
www.instagram.com/lantmateriet
 
Med vänliga hälsningar,
Grigory Rechistov
With best regards,
Grigory Rechistov
 ___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-hr] Krivi editi

[Ivan Habunek]

On Wed, 12 Feb 2020, at 11:41, Janko Mihelić wrote:
> Jel kontantiran? Mogu ja ako još nitko nije.

 Nisam još imao vremena, slobodno ga ti priupitaj.

Pozdrav,
-- Ivan

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

Re: [Talk-hr] Krivi editi

[Janko Mihelić]

Jel kontantiran? Mogu ja ako još nitko nije.

uto, 11. velj 2020. u 03:57 Matija Nalis <
mnalis-openstreetmapl...@voyager.hr> napisao je:

> da, idealno bi bilo kontaktirati autora, i vidjeti zasto to prepravlja?
>
> On Mon, Feb 10, 2020 at 11:42:26AM +0100, Ivan Habunek wrote:
> > Bok ekipa,
> >
> > Uočio sam na OSM Inspektoru da su krivo tagana stajališta autobusa u
> Velikoj gorici.
> >
> > Pogledao sam povijest i ispada da ih je Janjko ispravno unio kao
> public_transport=platform ali onda je fran_B prepravio u
> platform=stop_position, što je neispravno.
> >
> > Što se radi u ovakvoj situaciji? Kako se reverta? Trebamo kontaktirati
> autora i pričati s njime? :)
> >
> > Inspektor:
> https://tools.geofabrik.de/osmi/?view=pubtrans_stops=16.07700=45.71120=18=stops_,stops_positions,stops_classic,stops_positions_not_on_ways,platforms_,platforms_nodes,platforms_ways
> >
> > Changeset: https://www.openstreetmap.org/changeset/80529745
> >
> > History jednog od nodeova:
> http://osm.mapki.com/history/node.php?id=7038174257
> >
> > Pozdrav,
> > -- Ivan
> >
> > ___
> > Talk-hr mailing list
> > Talk-hr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-hr
>
> --
> Opinions above are GNU-copylefted.
>
> ___
> Talk-hr mailing list
> Talk-hr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-hr
>
___
Talk-hr mailing list
Talk-hr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-hr

[talk-cz] Chybejici prohlaseni prav vlastnika na zomato.com

[Jakub Jelen]

Zdravim,
jen pro informaci, dnes jsem narazil na chybejici prohlaseni prav
vlastnika na zomato.com. V interaktivni mape je to spravne, ale
minimapa se zobrazuje bez prislusneho radku [1]. Uz jsem jim psal, tak
uvidime co z toho bude. Sem pro poradek, at mame zaznam.

[1] https://www.zomato.com/skog

Jakub

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

Re: [Talk-GB] MapThePaths: possible interrupted service this week

[Nick Whitelegg]

... sorry for all the emails: but further update - it's now up, but running 
HTTP not HTTPS (as it used to).
Hopefully HTTPS will be enabled very soon.

Thanks,
Nick




From: Nick Whitelegg 
Sent: 12 February 2020 09:59
To: Talk-GB 
Subject: Re: [Talk-GB] MapThePaths: possible interrupted service this week


Hello everyone,

To update: the site is transferred now but I am having some DNS issues 
(relating I think to IPv6 DNS records) meaning that the site is still 
inaccessible.
I have asked the new hosting provider about this; basically I want to run it as 
HTTPS but these DNS issues are preventing the certificate from being installed.

Apologies for the ongoing downtime, hopefully this will be resolved in the next 
day or so.

Thanks,
Nick


From: Nick Whitelegg 
Sent: 10 February 2020 11:21
To: Talk-GB 
Subject: [Talk-GB] MapThePaths: possible interrupted service this week

Hello everyone,

Just a heads-up: I am transferring MapThePaths to the same server I use to run 
my other projects, Hikar and OpenTrailView, this week.

This means that there may be interruption or unavailability in service, 
starting today.

Thanks,
Nick

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

[OSM-talk-fr] Structures de soins en addictologie (CSAPA, CAARUD…)

[Yves P.]

Bonjour,

La page FR:Comment cartographier un (santé) 
 
décrit comment définir un Centre de Soins d'Accompagnement et de Prévention en 
Addictologie 

 (CSAPA).
J’ai ajouté Centre d’accueil et d’accompagnement à la réduction des risques 
pour usagers de drogues 

 (CAARUD)

Plusieurs questions se posent :

Quelles valeurs de social_facility utiliser ?
Les CSAPA sont parfois des lieux d’hébergement (group_home ou assisted_living 
?) mais ce n’est pas la règle.
Faut-il alors proposer ambulatory_care ou outreach ?

Les CAARUD peuvent être mobiles : les intervenants éducateurs ou infirmiers se 
déplacent alors dans d’autres structures, aux domiciles des usagers, voir dans 
la rue.
Faut-il utiliser ambulatory_care (la page FR:Key:social_facility 

 parle de « maraude » mais ça ne correspond pas à l’usage en France) ou plutôt 
outreach (ce qui correspond bien à la définition de wikipedia en anglais 
) ?

Comment nommer ces structures pour les retrouver facilement avec Nominatim tout 
en ne surchargeant pas la carte ?
Les CSAPA et/ou CAARUD sont souvent des structures internes à des associations 
loi 1901, parfois à des cliniques ou hôpitaux.
Ces termes (CSAPA, CAARUD) ne font pas à proprement partie du nom.

Pour celui de Lons-le-Saunier 
,
 j’ai utilisé :

name
Passerelle 39
Le nom de l’association locale
short_name
CSAPA

alt_name
Centre de Soins, d'Accompagnement et de Prévention en Addictologie

operator
Oppelia
Le nom de l’association « mére »

Il y a aussi un CAARUD à l’autre bout du bâtiment (qui est aussi mobile 
certains jours de la semaine).

Faut-il créer un autre POI avec le même nom ?
Ou regrouper CAARUD et CSAPA dans le même POI avec des valeurs multiples pour 
short_name, alt_name et type:FR:FINESS ?

Faut-il nettoyer les données OSM ?
Une recherche (NOMINATIM) avec le terme CSAPA 
 renvoi « Clinique », « 
Hospital », « Service social » , « Salle polyvalente ».

Une recherche Overpass avec "social_facility:for"=drug_addicted en France 
 montre que les tags amenity=social_facility 
et social_facility=* ne sont pas toujours présents.

Il y a parfois uniquement office=association comme tag principal.

La recherche Overpass globale  montre 
l’utilisation des tags suivants :
amenity=college, clinic, doctors, hospital, nursing_home, social_centre ou 
social_facility

social_facility=advice, ambulatory_care, assisted_living, clinic, day_care, 
day_centre, drugs, group_home, healthcare, nursing_home, outreach, 
rehabilitation, residential_home, safe_injection_site, shelter, social_club, 
workshop ou yes

Et parfois quelques tags complémentaires :
health_facility:type=counselling_centre

health_service:counselling=yes
health_service:prevention=yes

healthcare:speciality=addiction, physiatry ou psychiatry
healthcare=clinic, doctor, hospital ou rehabilitation

counselling_type:addiction=yes
counselling_type:drugs=yes

—
Yves

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

Re: [Talk-GB] MapThePaths: possible interrupted service this week

[Nick Whitelegg]

Hello everyone,

To update: the site is transferred now but I am having some DNS issues 
(relating I think to IPv6 DNS records) meaning that the site is still 
inaccessible.
I have asked the new hosting provider about this; basically I want to run it as 
HTTPS but these DNS issues are preventing the certificate from being installed.

Apologies for the ongoing downtime, hopefully this will be resolved in the next 
day or so.

Thanks,
Nick


From: Nick Whitelegg 
Sent: 10 February 2020 11:21
To: Talk-GB 
Subject: [Talk-GB] MapThePaths: possible interrupted service this week

Hello everyone,

Just a heads-up: I am transferring MapThePaths to the same server I use to run 
my other projects, Hikar and OpenTrailView, this week.

This means that there may be interruption or unavailability in service, 
starting today.

Thanks,
Nick

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

Re: [Talk-it] vie ferrate e vie di arrampicata

[Alfredo Gattai]

>
> Non capisco, di solito la definizione di un sentiero per quanto riguarda
> la difficoltà, viene espressa con la massima difficoltà, quindi una
> ferrata su di un sentiero CAI, è un tratto dello stesso o il tratto
> stesso, e quindi definisce la massima difficoltà dello stesso in un
> contestuale catasto CAI.
>
> Non seguo il perchè fare due relazioni distinte e non i tag sul tratto
> interessato.
>

Lo scopo e' quello di distinguere nettemente una via ferrata da un percorso
definito escursionistico.
Se un percorso ha al suo interno un breve tratto attrezzato con difficolta'
che non ecceda EEA:F potra' rimanere come route=hikibg e la sua
cai_scale=EEA:F.
I singoli tratti avranno il loro sac_scale e le loro caratteristiche.

Quando invece la difficolta' aumenta ed il percorso diventa una via ferrata
allora va definito come tale.
La ragione di fare una relazione invece della singola way sta nel fatto che
anche le ferrate spesso hanno tratti di collegamento che magari sono
semplici path percio' per collegare il tutto l'opzione migliore sembra
essere la relazione.

All'inizio di Marzo avremo in sede centrale una conversazione sulle scale
di difficolta' e sula distinzione fra sentiero attrezzato e via ferrata. A
valle di cio' poi potremo andare avanti con la definizione della mappatura.

Una volta raggiunto un minimo di standardizzazione postero' sul github di
waymarkedtrails una richiesta di localizzazione con delle proposte di
rendering in modo da dare un minimo di chiarezza su cosa e' cosa quando si
guarda la mappa.

Alfredo


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

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[stevea]

On Feb 12, 2020, at 12:28 AM, Martin Koppenhoefer  
wrote:
> Start with "If A, then B" where A is "it is on the ground" and B is "you may 
> map it."  Now, try the contrapositive "If not B, then not A" (in logic 
> notation:  ¬B -> ¬A). 
> 
> this is not how complex situations work. "If its black it is not colored" 
> does not mean that if its not colored it must be black (could be white, gray, 
> etc.).

You make my point for me, Martin, and Colin reiterates it  Our OTG "rule" fails 
a simple logic test which should always be true ("proof by contrapositive") but 
we in OSM (this mail-list, other places) say "A -> B is true, but ¬B -> ¬A (its 
contrapositive) is not true!"  That's broken logic about OTG, stripped to its 
minimum.

It is exactly because OTG is a complex situation (breaking logic) that we must 
improve OTG.  If we can't state a logical rule which logically works, let's at 
least start with a rule that has some exceptions we all agree upon:  we map 
what's OTG, but not some boundaries, mountain ranges, oceans... even though 
they are neither OTG nor signed.  We can improve OTG from there.  Because that 
is what OSM actually does.

Not to combine TOO much into one post:  Frederik makes a good point that we 
shouldn't blindly defer to authorities, however, when "an authoritative source" 
is the ONLY thing which can provide a name (for example) in the absence of a 
sign or other OTG evidence, how ELSE are we supposed to know what to tag 
something?  Please don't answer "ask locals" or "everybody just knows that" as 
neither is a very good component of a "rule," as OTG claims to be (but isn't).

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

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Frederik Ramm]

Hi,

On 2020-02-12 10:28, Colin Smale wrote:
> Where a boundary coincides with the centre line of
> a road for example, and there is a discrepancy in OSM between the
> locations of the two, there should be a recognition that the
> professionally surveyed locations are more likely to be correct

I disagree.

What you are requesting here is that we blindly defer to authorities. "I
cannot verify this - but a professional surveyor with his $10k equipment
claims it is so - hence I guess I have to believe it."

I think this is not how OpenStreetMap should be operating. I can see how
to a professional surveyor the idea must be painful that someone comes
along with their rubbish equipment and makes a change, but we *are* a
project of hobbyists and volunteers, and something that a hobbyist and
volunteer cannot verify ("don't touch this unless you invest $10k in
equipment first!!!") should not be in OSM, and we should not worship
precision that we cannot create ourselves.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-it] overpass_api trasformare attic data

[Andrea Albani]

Ciao,

se usi out meta; ti ritrovi con un file osm "normale".

Intendi ottenere dati come apparivano ad una certa data ? per intenderci
una cosa del genere ?

[out:xml][timeout:25][date:"2013-05-06T16:00:00Z"];
way["waterway"]({{bbox}});
(._;>;);
out meta;



Il giorno mer 12 feb 2020 alle ore 10:22 Luca Delucchi 
ha scritto:

> Ciao a tutti,
>
> se con Overpass API si usa il filtro date ritorna un file osm attic data
> [0].
> È possibile estrarre dall'attic date un file osm con solo l'ultima
> versione dei dati?
>
>
> [0] https://wiki.openstreetmap.org/wiki/Attic_Data
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Shohreh]

Jérôme Seigneuret-3 wrote
> penses à le décrire sur le wiki en Anglais et Français au moins

Fait.



--
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] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-12 09:28, Martin Koppenhoefer wrote:

> I believe it is a misconception to think it must be "visible" on the ground, 
> rather it must be determinable on the ground / "in loco". There might well be 
> nothing to "see", but you could still check on the ground, by talking to the 
> local people, how to map something (particularly, how to call it). 
> 
>> Start with "If A, then B" where A is "it is on the ground" and B is "you may 
>> map it."  Now, try the contrapositive "If not B, then not A" (in logic 
>> notation:  ¬B -> ¬A).
> 
> this is not how complex situations work. "If its black it is not colored" 
> does not mean that if its not colored it must be black (could be white, gray, 
> etc.).

 And this is why we should not try to map a continuum of possibilities
onto a binary model. The OTG rule/guideline needs to accommodate these
shades of grey. A rule that leads to so much discussion and so many
exceptions is clearly not a good rule in its current form. Lets do some
process improvement here! 

I want to come back to a point I made a few days ago as well, concerning
location accuracy. If a point (possibly on an admin boundary) is
imported into OSM from a source which has used cm-level surveying
equipment, it is nothing short of WRONG if Joe Bloggs comes along with
his $100 smartphone and moves that point based on a 3-satellite 2D GPS
fix with a 100m GDOP. Where a boundary coincides with the centre line of
a road for example, and there is a discrepancy in OSM between the
locations of the two, there should be a recognition that the
professionally surveyed locations are more likely to be correct - so in
this example the highway should be moved to fit the boundary, and not
the other way around! This professional data provides an extremely
important collection of reference points, to which other data should be
aligned - just like the trig points of older survey systems. OTG IS NOT
ALWAYS BETTER! 

Elevations suffer from the same issues - except that the accuracy from
GPS is even worse. Don't get me started on the differing definitions of
"sea level" leading to meaningless elevations in OSM (because they don't
specify to which datum they are relative).___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-it] overpass_api trasformare attic data

[Luca Delucchi]

Ciao a tutti,

se con Overpass API si usa il filtro date ritorna un file osm attic data [0].
È possibile estrarre dall'attic date un file osm con solo l'ultima
versione dei dati?


[0] https://wiki.openstreetmap.org/wiki/Attic_Data

-- 
ciao
Luca

www.lucadelu.org

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

Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Florimond Berthoux]

Le mer. 12 févr. 2020 à 05:08, Jérôme Amagat  a
écrit :

>
>
> Le mar. 11 févr. 2020 à 15:17, Rpnpif via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>
>> Je voudrais proposer de modifier la façon de traiter les communes
>> nouvelles françaises dans OSM.
>>
>> Je considère qu'une nouvelle commune devrait être enregistrée de la même
>> façon qu'une ancienne commune issue de fusion de plusieurs communes.
>>
>> C'est traité de la même façon dans osm.
> Comme la grande majorité des communes porte le nom du village (ou la
> ville) principal on confond souvent les 2 mais dans osm la commune et le
> village sont indiqués de 2 façons différentes.
> relation boundary admin_level=8 pour les communes et place=village pour
> les village.
>
> Pour des communes fusionnées il y a longtemps avec un nom de commune
> différents de celui du village principal, j'ai des cas pas loin de chez moi
> :
> Hautecourt-Romanèche : https://www.openstreetmap.org/relation/140516
> Bohas-Meyriat-Rignat : https://www.openstreetmap.org/relation/140527
> fusionnées dans les années 70
> Pour les 2, les noms de communes sont l'addition des noms des anciennes
> communes.
>
> Pour des communes qui ne porte pas le nom d'un village, je connais Alleuze
> : https://www.openstreetmap.org/relation/1223480 qui porte le nom d'un
> château en ruine.
> J'ai pas d'autres exemples en tête mais il y en a d'autres.
>

La plus part des noms de communes sous la forme XXX leṣ|lès|des|en|sur...
sont souvent que des formes administrative pour différencier des homonymies
à l’échelle nationale.
Exemple : j’ai habité dans la commune de Lassay les Châteaux en campagne,
et j’allais au collège à Lassay.

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

Re: [Talk-it] Problemi strutturali

[Martin Koppenhoefer]

Am Mo., 27. Jan. 2020 um 14:24 Uhr schrieb Martin Koppenhoefer <
dieterdre...@gmail.com>:

> Come facciamo, qualcuno conosce i dettagli e ci può aiutare a trovare la
> posizione giusta? Molto probabilmente, la linea di costa non fa parte di
> nessun confine amministrativo.
>


Mi rispondo da solo, aggiungendo un riferimento a taginfo italia:
https://taginfo.geofabrik.de/europe/italy/tags/natural=coastline#combinations

Attualmente, secondo taginfo it (comprende anche parte della Tunisia,
Corsica e Croazia / Slovenia ecc.), abbiamo un 20% di casi dove lo stesso
way ha anche il tag "admin_level". Vogliamo correggere?

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

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Martin Koppenhoefer]

Am Mi., 12. Feb. 2020 um 01:29 Uhr schrieb stevea :

> On Feb 11, 2020, at 3:45 PM, Mateusz Konieczny via talk <
> talk@openstreetmap.org> wrote:
> > OTG is not "everything must be mapped on survey", it means
> > that direct survey (what is actually existing) overrides official data,
> opinions and desires.
>
> I thank Mateusz for making (reiterating?) this important point.



+1



> I believe some of us think OTG is an absolute rule which states "map what
> is on the ground."  Logically, we should be able to "derive" the
> potentially equivalent statement "if you canNOT see it on-the-ground, you
> may NOT (should not) map it."  But that's not how we map, due to numerous
> counter-examples (some boundaries, mountain ranges, oceans...).



I believe it is a misconception to think it must be "visible" on the
ground, rather it must be determinable on the ground / "in loco". There
might well be nothing to "see", but you could still check on the ground, by
talking to the local people, how to map something (particularly, how to
call it).



> Start with "If A, then B" where A is "it is on the ground" and B is "you
> may map it."  Now, try the contrapositive "If not B, then not A" (in logic
> notation:  ¬B -> ¬A).



this is not how complex situations work. "If its black it is not colored"
does not mean that if its not colored it must be black (could be white,
gray, etc.).

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