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

[Jérôme Seigneuret]

Bonjour,

Il me semble que pour les conventions de nommage on évite des accents
*ref:FR:Tisséo
*dans les balises


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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-GB] "One million solar panels! If only we knew where they were..."

[Jez Nicholson]

Nice to see Dan Stilwell and Jack Kelly writing about the solar panels
project on
https://climatechangenews.com/2020/02/12/one-million-solar-panels-knew/
also an honourary mention for Russ Garrett and Open Infrastructure Map.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [talk-au] [OSGeo Oceania] FOSS4G SotM Oceania 2019 tree planting day

[Edoardo Neerhut]

Ok thanks for clarifying.

On Wed, 12 Feb 2020 at 16:04, adam steer  wrote:

> Hi Ed (and all)
>
> Thanks! I’m filling out a filming permission form for 14/15/16 August.
>
> Ideally flights will take place the day before, or early on the same day
> before people arrive (weather dependent); it won’t be practical to
> undertake mapping missions and comply with CASA regulations while people
> are planting / moving around on the site. The day after is there just in
> case weather isn’t kind… and we might want to capture trees at the start of
> their life as well.
>
> Just had a thought strike me - is anyone in academia listening who wants
> to start a project on yellow box woodland development? good opportunity
> here… ;)
>
> Cheers,
>
> Adam
>
>
>
> On Wed, 12 Feb 2020 at 15:44, Edoardo Neerhut  wrote:
>
>> Love your work Adam. And thanks to Tony and Mick as well.
>>
>> In terms of the pre-planting aerial survey, would you do that on the day
>> itself if permission is granted?
>>
>> On Wed, 12 Feb 2020 at 11:52, adam steer  wrote:
>>
>>> Hi all
>>>
>>> I'm excited to report that the FOSS4G SotM Oceania 2019 tree planting
>>> program has been scheduled for 15 August 2020. Here is the Parks Victoria
>>> event information:
>>>
>>>
>>> https://www.parkconnect.vic.gov.au/Volunteer/public-planned-activity/?id=c38ff798-914c-ea11-b698-0003ff6f5db4
>>>
>>> If you want to attend and plant trees, great! You need to register as a
>>> volunteer with Parks Victoria using the ‘Register with ParkConnect’ button
>>> on the link above.
>>>
>>> We hope to run some free, volunteer-run mapping events on/around the
>>> day. Full details TBA, some ideas are:
>>> - conduct a pre-planting aerial survey (subject to Parks Victoria
>>> approval)
>>> - collect locations of all the trees (potentially also running a hands
>>> on QField / Input workshop)
>>> - add trees to OSM (along with any other salient features that are
>>> missing)
>>>
>>> Ideally everyone attending will also help plant trees - so please
>>> register with ParkConnect if you plan to attend in any capacity.
>>>
>>> Again, thanks to this community and especially the FOSS4G SotM Oceania
>>> organising committee for their moral and financial support. I'd like to
>>> specifically thank Tony Forster, who first suggested this project and has
>>> done much of the on-ground logistics (getting support of Parks Victoria and
>>> linking us up with local organisations / suppliers); and Mick van de Vreede
>>> of Parks Victoria, who has help line a lot of stuff up to help this happen.
>>>
>>> Please feel free to ask any questions by responding to list posts, or
>>> contact me directly.
>>>
>>> Regards,
>>>
>>> Adam
>>> ___
>>> Oceania mailing list
>>> ocea...@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/oceania
>>>
>>
>
> --
> Dr. Adam Steer
> http://spatialised.net
> https://www.researchgate.net/profile/Adam_Steer
> http://au.linkedin.com/in/adamsteer
> http://orcid.org/-0003-0046-7236
> +61 427 091 712 ::  @adamdsteer
>
> Suits are bad for business: http://www.spatialised.net/business-penguins/
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] [OSGeo Oceania] FOSS4G SotM Oceania 2019 tree planting day

[adam steer]

Hi Ed (and all)

Thanks! I’m filling out a filming permission form for 14/15/16 August.

Ideally flights will take place the day before, or early on the same day
before people arrive (weather dependent); it won’t be practical to
undertake mapping missions and comply with CASA regulations while people
are planting / moving around on the site. The day after is there just in
case weather isn’t kind… and we might want to capture trees at the start of
their life as well.

Just had a thought strike me - is anyone in academia listening who wants to
start a project on yellow box woodland development? good opportunity here…
;)

Cheers,

Adam



On Wed, 12 Feb 2020 at 15:44, Edoardo Neerhut  wrote:

> Love your work Adam. And thanks to Tony and Mick as well.
>
> In terms of the pre-planting aerial survey, would you do that on the day
> itself if permission is granted?
>
> On Wed, 12 Feb 2020 at 11:52, adam steer  wrote:
>
>> Hi all
>>
>> I'm excited to report that the FOSS4G SotM Oceania 2019 tree planting
>> program has been scheduled for 15 August 2020. Here is the Parks Victoria
>> event information:
>>
>>
>> https://www.parkconnect.vic.gov.au/Volunteer/public-planned-activity/?id=c38ff798-914c-ea11-b698-0003ff6f5db4
>>
>> If you want to attend and plant trees, great! You need to register as a
>> volunteer with Parks Victoria using the ‘Register with ParkConnect’ button
>> on the link above.
>>
>> We hope to run some free, volunteer-run mapping events on/around the day.
>> Full details TBA, some ideas are:
>> - conduct a pre-planting aerial survey (subject to Parks Victoria
>> approval)
>> - collect locations of all the trees (potentially also running a hands on
>> QField / Input workshop)
>> - add trees to OSM (along with any other salient features that are
>> missing)
>>
>> Ideally everyone attending will also help plant trees - so please
>> register with ParkConnect if you plan to attend in any capacity.
>>
>> Again, thanks to this community and especially the FOSS4G SotM Oceania
>> organising committee for their moral and financial support. I'd like to
>> specifically thank Tony Forster, who first suggested this project and has
>> done much of the on-ground logistics (getting support of Parks Victoria and
>> linking us up with local organisations / suppliers); and Mick van de Vreede
>> of Parks Victoria, who has help line a lot of stuff up to help this happen.
>>
>> Please feel free to ask any questions by responding to list posts, or
>> contact me directly.
>>
>> Regards,
>>
>> Adam
>> ___
>> Oceania mailing list
>> ocea...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/oceania
>>
>

-- 
Dr. Adam Steer
http://spatialised.net
https://www.researchgate.net/profile/Adam_Steer
http://au.linkedin.com/in/adamsteer
http://orcid.org/-0003-0046-7236
+61 427 091 712 ::  @adamdsteer

Suits are bad for business: http://www.spatialised.net/business-penguins/
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-ja] 「WikiProject」プレフィックスの削除 / Removing "WikiProject" prefix

[Satoshi IIDA]

いいだです。
+1 to applyです！



2020年2月11日(火) 6:32 Daniel Capilla :

> [自動翻訳]
>
> こんにちは、
>
>
> 私はスペイン出身のダニエルです。日本マッピングプロジェクトに関連するWikiページの名前を変更して、ページ名の規則[1]に従って「Wikiproject」プレフィックスを削除したいと思います。
>
> 日本マッピングプロジェクトに関連するページの名前は、Wiki規約で推奨されているように、「Wikiproject
> Japan」ではなく「Japan」（場所の名前）になります。これは、米国[2]、カナダ[3]、スペイン[4]、オーストラリア[5]、ニュージーランド[6]、南アフリカ[7]、フランス[8]、およびすべてですでに行った変更ですWikiのスペイン語圏[9]。イスラエル、デンマーク、ノルウェー、イギリス、イタリア、ドイツ、インド、ロシア、フィリピンのページも改名されました。
>
>
> 「WikiProject」プレフィックスを持つすべてのページは自動的にリダイレクトされます。いずれの場合もリンク切れはありません。今と同じように、すべてが正しく機能することを確認します。
>
> あなたはそのアイデアが好きですか？あなたがそこにコメントしたい場合のために、私はこのメッセージをwikiに投稿しました[10]。
>
> ご清聴ありがとうございました！スペインからのご挨拶。
>
> よろしく、
> ダニエル
>
>
> [English]
>
> Hi,
>
> I am Daniel, from Spain. I would like to change the name of the wiki pages
> related to the Japan mapping project to remove the "Wikiproject" prefix
> according to the pages name conventions [1].
>
> The name of the pages related to the Japan mapping project would be
> "Japan" (name of place) instead of "Wikiproject Japan", as recommended by
> the wiki conventions. It is a change that I have already made in United
> States [2], Canada [3], Spain [4], Australia [5], New Zealand [6], South
> Africa [7], France [8], and all Spanish-speaking countries [9] on the Wiki.
> The pages of Israel, Denmark, Norway, United Kingdom, Italy, Germany,
> India, Russia and Philippines have also been renamed.
>
> All pages with "WikiProject" prefix will be redirected automatically.
> There will be no broken links in any case.  I'll make sure everything works
> correctly, just like now.
>
> Do you like the idea? I have posted this message on the wiki in case you
> prefer to comment there [10].
>
> Thank you for you attention! Greetings from Spain.
>
> Regards,
> Daniel
>
> [1]
>
> https://wiki.openstreetmap.org/wiki/Wiki_organisation#Pages_naming_convention
> [2] https://wiki.openstreetmap.org/wiki/United_States
> [3] https://wiki.openstreetmap.org/wiki/Canada
> [4] https://wiki.openstreetmap.org/wiki/ES:Spain
> [5] https://wiki.openstreetmap.org/wiki/Australia
> [6] https://wiki.openstreetmap.org/wiki/New_Zealand
> [7] https://wiki.openstreetmap.org/wiki/South_Africa
> [8] https://wiki.openstreetmap.org/wiki/France
> [9]
> https://wiki.openstreetmap.org/wiki/Category:Spanish_speaking_countries
> [10]
> https://wiki.openstreetmap.org/wiki/Talk:WikiProject_Japan#Removing_.22WikiProject.22_prefix
> ___
> 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: [talk-au] [OSGeo Oceania] FOSS4G SotM Oceania 2019 tree planting day

[Edoardo Neerhut]

Love your work Adam. And thanks to Tony and Mick as well.

In terms of the pre-planting aerial survey, would you do that on the day
itself if permission is granted?

On Wed, 12 Feb 2020 at 11:52, adam steer  wrote:

> Hi all
>
> I'm excited to report that the FOSS4G SotM Oceania 2019 tree planting
> program has been scheduled for 15 August 2020. Here is the Parks Victoria
> event information:
>
>
> https://www.parkconnect.vic.gov.au/Volunteer/public-planned-activity/?id=c38ff798-914c-ea11-b698-0003ff6f5db4
>
> If you want to attend and plant trees, great! You need to register as a
> volunteer with Parks Victoria using the ‘Register with ParkConnect’ button
> on the link above.
>
> We hope to run some free, volunteer-run mapping events on/around the day.
> Full details TBA, some ideas are:
> - conduct a pre-planting aerial survey (subject to Parks Victoria approval)
> - collect locations of all the trees (potentially also running a hands on
> QField / Input workshop)
> - add trees to OSM (along with any other salient features that are missing)
>
> Ideally everyone attending will also help plant trees - so please register
> with ParkConnect if you plan to attend in any capacity.
>
> Again, thanks to this community and especially the FOSS4G SotM Oceania
> organising committee for their moral and financial support. I'd like to
> specifically thank Tony Forster, who first suggested this project and has
> done much of the on-ground logistics (getting support of Parks Victoria and
> linking us up with local organisations / suppliers); and Mick van de Vreede
> of Parks Victoria, who has help line a lot of stuff up to help this happen.
>
> Please feel free to ask any questions by responding to list posts, or
> contact me directly.
>
> Regards,
>
> Adam
> ___
> Oceania mailing list
> ocea...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/oceania
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

[Jérôme Amagat]

Le mar. 11 févr. 2020 à 15:17, Rpnpif via Talk-fr 
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.

Pour ce qui est de l'utilisation de place=municipality :
l'ajout de la population de la municipalité serait logique.
Mais par contre, ce n'est pas l'admin_centre de la commune. (label ?)
Par contre où placer le node, dans un endroit dégagé pour pouvoir avoir le
nom des villages qui apparaissent aussi, au centre de la commune ou près de
l'admin_centre de la commune ?

:) par contre, 2 règles importantes d'osm serait enfreintes, "One feature,
one OSM element" et "ne pas taguer pour le rendu" :)
___
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

[Pierre Béland via talk]

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.

Your answer about polygons is simply a spin rethoric form (une pirouette) to 
ignore the problem. Should we rename this project OpenEurope ?
Pierre 
 

Le mardi 11 février 2020 18 h 49 min 26 s UTC−5, Mateusz Konieczny via talk 
 a écrit :  
 
 


Feb 12, 2020, 00:07 by talk@openstreetmap.org:

Feb 11, 15:59, stevea wrote :

> Rather than get snarled in counter-examples, let's discuss how OTG isn't and 
> can't be strictly 
> followed in many cases.  It IS followed in the majority of cases, but in 
> those corner cases where 
> it isn't, because it can't be ("nothing" is OTG), must be realistically 
> addressed, likely in our wiki 
> where we state the "rule" today, though going forward much better state a 
> "guideline".  I think 
> we can get there, but it remains under discussion / construction.

I agree with this and I adds some other aspects to take into account below. The 
areas not yet mapped in OSM have characteristics quite different than the 
industrialiased regions / countries. And we cannot realistically count on 
mappers to walk or cycle through huge isolated areas. We cannot expect people 
that figth to survive, that have no good internet connexion to map intensively 
there neighboorhood. And more then mappers, we need to think where we need to 
revise OSM. 

Note that it is not violating OTG. OTG is not "everything must be mapped on 
survey", it means
that direct survey (what is actually existing) overrides official data, 
opinions and desires.

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.

??? just do not create unreasonably large multipolygons (or split existing, 
possibly undo import
if it makes area uneditable and do it right).
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[talk-au] FOSS4G SotM Oceania 2019 tree planting day

[adam steer]

Hi all

I'm excited to report that the FOSS4G SotM Oceania 2019 tree planting
program has been scheduled for 15 August 2020. Here is the Parks Victoria
event information:

https://www.parkconnect.vic.gov.au/Volunteer/public-planned-activity/?id=c38ff798-914c-ea11-b698-0003ff6f5db4

If you want to attend and plant trees, great! You need to register as a
volunteer with Parks Victoria using the ‘Register with ParkConnect’ button
on the link above.

We hope to run some free, volunteer-run mapping events on/around the day.
Full details TBA, some ideas are:
- conduct a pre-planting aerial survey (subject to Parks Victoria approval)
- collect locations of all the trees (potentially also running a hands on
QField / Input workshop)
- add trees to OSM (along with any other salient features that are missing)

Ideally everyone attending will also help plant trees - so please register
with ParkConnect if you plan to attend in any capacity.

Again, thanks to this community and especially the FOSS4G SotM Oceania
organising committee for their moral and financial support. I'd like to
specifically thank Tony Forster, who first suggested this project and has
done much of the on-ground logistics (getting support of Parks Victoria and
linking us up with local organisations / suppliers); and Mick van de Vreede
of Parks Victoria, who has help line a lot of stuff up to help this happen.

Please feel free to ask any questions by responding to list posts, or
contact me directly.

Regards,

Adam
___
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

[stevea]

On Feb 11, 2020, at 3:45 PM, Mateusz Konieczny via talk 
 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.  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...).  So, a crucial way we DO map is "if it IS 
on-the-ground, then THAT is what we map."  The idea of "if OTG, map THAT" 
shouldn't be different, but is different from "if not OTG, you may NOT map 
this" (which isn't true, strictly speaking, due to counterexamples).  I think 
in logical terms this might be called "a fallacy of the contrapositive."  
Logically, this is problematic.

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).  Or, "You may not map it if it is not on the ground." 
Usually, "proof by contrapositive" works, as "a statement and its 
contrapositive are logically equivalent, in the sense that if the statement is 
true, then its contrapositive is true and vice versa."  But in OSM, this does 
NOT work, because of the preponderance of examples where ¬B -> ¬A fails:  in 
some cases we DO map it, even though it is not on the ground.  And therein lies 
what we have to fix:  proof by contrapositive fails, when it shouldn't 
(logically), because OSM has made and does make numerous exceptions.  Let's 
clarify how, when and why we do this, at least as a "first cut" at how we 
address this contradiction.

I hope that clarifies, it does help sharpen focus about OTG in my mind, simply 
by being stated clearly.  Well, stated logically — and for some, I realize, 
that might NOT be clear!

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

[Mateusz Konieczny via talk]

Feb 12, 2020, 00:07 by talk@openstreetmap.org:

> Feb 11, 15:59, stevea wrote :
>
> > Rather than get snarled in counter-examples, let's discuss how OTG isn't 
> > and can't be strictly 
> > followed in many cases.  It IS followed in the majority of cases, but in 
> > those corner cases where 
> > it isn't, because it can't be ("nothing" is OTG), must be realistically 
> > addressed, likely in our wiki 
> > where we state the "rule" today, though going forward much better state a 
> > "guideline".  I think 
> > we can get there, but it remains under discussion / construction.
>
> I agree with this and I adds some other aspects to take into account below. 
> The areas not yet mapped in OSM have characteristics quite different than the 
> industrialiased regions / countries. And we cannot realistically count on 
> mappers to walk or cycle through huge isolated areas. We cannot expect people 
> that figth to survive, that have no good internet connexion to map 
> intensively there neighboorhood. And more then mappers, we need to think 
> where we need to revise OSM. 
>
Note that it is not violating OTG. OTG is not "everything must be mapped on 
survey", it means
that direct survey (what is actually existing) overrides official data, 
opinions and desires.

> 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.
>
??? just do not create unreasonably large multipolygons (or split existing, 
possibly undo import
if it makes area uneditable and do it right).
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[marc marc]

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

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

[François Lacombe]

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 
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

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

[Pierre Béland via talk]

Feb 11, 15:59, stevea wrote :
> Rather than get snarled in counter-examples, let's discuss how OTG isn't and 
> can't be strictly 
> followed in many cases.  It IS followed in the majority of cases, but in 
> those corner cases where 
> it isn't, because it can't be ("nothing" is OTG), must be realistically 
> addressed, likely in our wiki 
> where we state the "rule" today, though going forward much better state a 
> "guideline".  I think 
> we can get there, but it remains under discussion / construction.
 
I agree with this and I adds some other aspects to take into account below. The 
areas not yet mapped in OSM have characteristics quite different than the 
industrialiased regions / countries. And we cannot realistically count on 
mappers to walk or cycle through huge isolated areas. We cannot expect people 
that figth to survive, that have no good internet connexion to map intensively 
there neighboorhood. And more then mappers, we need to think where we need to 
revise OSM. 

In Africa, I have often used ne highres imagery to retrace official imported 
border limits that had been traced prior to the availability of detailed aerial 
imageries.
Also there are remote areas like lake North of Quebec, where we cannot 
realistically go and walk to trace every lake contour or follow thousand of km 
of Power lines (+ bears, mosquitos), and we need some assistance for example to 
trace hundred of thousand lakes like this one (imagery, assisted mapping, 
imports ??).https://www.openstreetmap.org/way/75891758#map=11/61.3877/-73.4622
Mappers dont add wood cuts for roads and map styles take care of this. Could we 
have a similar rule applied for Power lines, rivers and lakes ? And any 
possibility to approach the landcover differently ? Mappers, Schema or 
Developpers problem ?

What can we do to approach more realistically the problems, to establish good 
basis for more mapping to come ?
Yes, let's avoid the problem saying this is the bad Canada imports. Or maybe, 
we should think to revise the OSM schema which is not well adapted for such 
areas.
There exist distinct Landcover layers like on this Maptiler OSM Vectorial Map  
with a distinct Landcover layer
https://openlayers.org/en/latest/examples/mapbox-style.html
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.
Yes the problems must be realistically adressed if we want to progress.
 
Pierre 
 

Le mardi 11 février 2020 15 h 59 min 12 s UTC−5, stevea 
 a écrit :  
 
 On Feb 11, 2020, at 12:05 PM, Mark Wagner  wrote:
> Have you actually been to the US-Canada border?  For thousands and
> thousands of kilometers, it's really obvious:
> https://upload.wikimedia.org/wikipedia/commons/a/aa/US-Canada_border_at_Crawford_State_Park_20130629.jpg
> 
> Even when it's not as obvious as in that photo, there are still
> frequent boundary cairns.  And yes, they're mapped in OSM:
> https://www.openstreetmap.org/node/1997617997

I have been there, and in British Columbia, as is your example.  There will 
always be counter-examples to a claim of "boundaries are not always obvious or 
indicated on-the-ground," (as you did, here, with a cutline in the real world 
some of these being mapped in OSM).  Same with mountain ranges, oceans / bodies 
of water, etc. that have no signage or evidence of them (named as they are) 
being OTG.  Simply stated, there ARE (and always will be) things we map which 
are not OTG, making OTG not a rule strictly followed.

However, we map these anyway, and by the thousand.  My point is that OSM 
shouldn't pretend that the OTG "rule" is absolute, as it isn't.  While I think 
all of us (even its original proponent in 2007, as Mikel stated earlier) agree 
that OTG is "an excellent guideline to be followed where it can be," others 
(Colin, Yuri) here have chimed in or infer that it can't realistically be 
absolute (as it isn't, and it can't).  Me, too.  There seems to be consensus 
that "Independent verifiability" is a crucial component of Good Practice in 
those cases where OTG cannot STRICTLY be followed, as in cases of invisible 
boundaries, oceans without signage, and mountain ranges where we are forced to 
concede "well, everybody simply KNOWS that these are 'The Alps' or 'The Rocky 
Mountains.'"  The solution here is "this (and its correct name) can be 
independently verified, that's "good enough for OSM" even without OTG evidence.

https://wiki.osm.org/wiki/Talk:Good_practice#Supplementing_and_clarifying_the_On_The_Ground_.22rule.22
 has input from Yuri and jeisenberg and I discussing whether unsigned routes 
qualify for this treatment (we can't see them OTG, but we map them anyway, as a 
public agency asserts their existence, though it hasn't signed them well).  
While routes like this are a relatively minor (lesser) concern about OTG, 
broader 

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

[stevea]

On Feb 11, 2020, at 2:41 PM, Mikel Maron  wrote:
> https://lists.openstreetmap.org/pipermail/talk/2020-February/083993.html

Thank you.  That's recent, and reminds me that I agreed with you as I (and I 
suspect others) support a yet-to-be, well-designed tagging protocol which 
clearly denotes these distinctions (national sovereignty vs. de facto control).

This dichotomy (as in Crimea) is one more area where OTG "fails" (mm, better 
stated:  "needs clarification").  The others (mountain ranges, oceans...) I 
mention in my previous (and lengthy) missives remain.  This not only makes more 
plain OTG's problems (at its edges, mostly) but brings the topic back to the 
(original thread's) issue of Crimea, which isn't an edge-case, but something 
which OSM continues to face.  While solutions don't seem easy or quickly 
forthcoming, I am heartened by good discussion here and in the Good Practices 
Talk page I linked earlier.

Yes, OTG has some work to do.  Again, I think we can get there.

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

Re: [OSM-talk] Acknowledgement for the wiki documentation

[François Lacombe]

Hi Daniel,

Thank you for your message, very encouraging to provide high quality of
documentation
Even if it consumes high amount of time sometimes

Translations are important also, great to see people involved in this :)

All the best

François

Le sam. 8 févr. 2020 à 22:22, Daniel Capilla  a écrit :

> Hi,
>
> I've been working on the translation of the wiki into Spanish for a long
> time, both creating new translations and updating the translations that
> become obsolete. In all this time I have been able to check the
> evolution of some pages of documentation in English, the way in which
> they have expanded in content over time and clarifying cases of use of
> tags that could be confusing initially.
>
> I have sent this message to the mailing list just to thank all users and
> contributors who help documenting the use of tags, projects, mappers'
> guides and other documentation pages on the OSM Wiki. It is an important
> work, a much appreciated and very valuable effort.
>
> Thanks to all of you!
>
> Greetings from Spain.
>
> Regards,
>
> Daniel
>
>
> ___
> 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: [OSM-talk-fr] ref et ref:FR

[François Lacombe]

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

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

[Mikel Maron]

https://lists.openstreetmap.org/pipermail/talk/2020-February/083993.html

* Mikel Maron * +14152835207 @mikel s:mikelmaron 

On Tuesday, February 11, 2020, 04:42:42 PM EST, stevea 
 wrote:  
 
 Thanks, Mikel, but may I please ask what you mean by "control boundaries?"
SteveA

> On Feb 11, 2020, at 1:36 PM, Mikel Maron  wrote:
> 
> btw, I think it's entirely compatible to follow On the Ground, with tagging 
> that recognizes the distinction between political boundaries and control 
> boundaries.
> 
> * Mikel Maron * +14152835207 @mikel s:mikelmaron


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

[stevea]

Thanks, Mikel, but may I please ask what you mean by "control boundaries?"
SteveA

> On Feb 11, 2020, at 1:36 PM, Mikel Maron  wrote:
> 
> btw, I think it's entirely compatible to follow On the Ground, with tagging 
> that recognizes the distinction between political boundaries and control 
> boundaries.
> 
> * Mikel Maron * +14152835207 @mikel s:mikelmaron


___
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]

btw, I think it's entirely compatible to follow On the Ground, with tagging 
that recognizes the distinction between political boundaries and control 
boundaries.
* Mikel Maron * +14152835207 @mikel s:mikelmaron 

On Tuesday, February 11, 2020, 03:55:48 PM EST, stevea 
 wrote:  
 
 On Feb 11, 2020, at 12:05 PM, Mark Wagner  wrote:
> Have you actually been to the US-Canada border?  For thousands and
> thousands of kilometers, it's really obvious:
> https://upload.wikimedia.org/wikipedia/commons/a/aa/US-Canada_border_at_Crawford_State_Park_20130629.jpg
> 
> Even when it's not as obvious as in that photo, there are still
> frequent boundary cairns.  And yes, they're mapped in OSM:
> https://www.openstreetmap.org/node/1997617997

I have been there, and in British Columbia, as is your example.  There will 
always be counter-examples to a claim of "boundaries are not always obvious or 
indicated on-the-ground," (as you did, here, with a cutline in the real world 
some of these being mapped in OSM).  Same with mountain ranges, oceans / bodies 
of water, etc. that have no signage or evidence of them (named as they are) 
being OTG.  Simply stated, there ARE (and always will be) things we map which 
are not OTG, making OTG not a rule strictly followed.

However, we map these anyway, and by the thousand.  My point is that OSM 
shouldn't pretend that the OTG "rule" is absolute, as it isn't.  While I think 
all of us (even its original proponent in 2007, as Mikel stated earlier) agree 
that OTG is "an excellent guideline to be followed where it can be," others 
(Colin, Yuri) here have chimed in or infer that it can't realistically be 
absolute (as it isn't, and it can't).  Me, too.  There seems to be consensus 
that "Independent verifiability" is a crucial component of Good Practice in 
those cases where OTG cannot STRICTLY be followed, as in cases of invisible 
boundaries, oceans without signage, and mountain ranges where we are forced to 
concede "well, everybody simply KNOWS that these are 'The Alps' or 'The Rocky 
Mountains.'"  The solution here is "this (and its correct name) can be 
independently verified, that's "good enough for OSM" even without OTG evidence.

https://wiki.osm.org/wiki/Talk:Good_practice#Supplementing_and_clarifying_the_On_The_Ground_.22rule.22
 has input from Yuri and jeisenberg and I discussing whether unsigned routes 
qualify for this treatment (we can't see them OTG, but we map them anyway, as a 
public agency asserts their existence, though it hasn't signed them well).  
While routes like this are a relatively minor (lesser) concern about OTG, 
broader discussion continues here (in talk).  (I'm OK with that).  But lest my 
suggestion that we modify/soften OTG from a "hard rule" (which it isn't and 
cannot be) into a wishy-washy, too-ill-defined "guideline," please understand 
I'm stating OTG isn't a rule.  Rather, it is an excellent guideline to be 
followed where it can be and is, but it is a fact that it cannot be and is not 
always followed.  The particulars of how we better apply OTG going forward 
might be difficult to describe well and reach consensus upon, but we shouldn't 
let that deter us, even with disagreement.

Rather than get snarled in counter-examples, let's discuss how OTG isn't and 
can't be strictly followed in many cases.  It IS followed in the majority of 
cases, but in those corner cases where it isn't, because it can't be ("nothing" 
is OTG), must be realistically addressed, likely in our wiki where we state the 
"rule" today, though going forward much better state a "guideline".  I think we 
can get there, but it remains under discussion / construction.

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

[stevea]

On Feb 11, 2020, at 12:05 PM, Mark Wagner  wrote:
> Have you actually been to the US-Canada border?  For thousands and
> thousands of kilometers, it's really obvious:
> https://upload.wikimedia.org/wikipedia/commons/a/aa/US-Canada_border_at_Crawford_State_Park_20130629.jpg
> 
> Even when it's not as obvious as in that photo, there are still
> frequent boundary cairns.  And yes, they're mapped in OSM:
> https://www.openstreetmap.org/node/1997617997

I have been there, and in British Columbia, as is your example.  There will 
always be counter-examples to a claim of "boundaries are not always obvious or 
indicated on-the-ground," (as you did, here, with a cutline in the real world 
some of these being mapped in OSM).  Same with mountain ranges, oceans / bodies 
of water, etc. that have no signage or evidence of them (named as they are) 
being OTG.  Simply stated, there ARE (and always will be) things we map which 
are not OTG, making OTG not a rule strictly followed.

However, we map these anyway, and by the thousand.  My point is that OSM 
shouldn't pretend that the OTG "rule" is absolute, as it isn't.  While I think 
all of us (even its original proponent in 2007, as Mikel stated earlier) agree 
that OTG is "an excellent guideline to be followed where it can be," others 
(Colin, Yuri) here have chimed in or infer that it can't realistically be 
absolute (as it isn't, and it can't).  Me, too.  There seems to be consensus 
that "Independent verifiability" is a crucial component of Good Practice in 
those cases where OTG cannot STRICTLY be followed, as in cases of invisible 
boundaries, oceans without signage, and mountain ranges where we are forced to 
concede "well, everybody simply KNOWS that these are 'The Alps' or 'The Rocky 
Mountains.'"  The solution here is "this (and its correct name) can be 
independently verified, that's "good enough for OSM" even without OTG evidence.

https://wiki.osm.org/wiki/Talk:Good_practice#Supplementing_and_clarifying_the_On_The_Ground_.22rule.22
 has input from Yuri and jeisenberg and I discussing whether unsigned routes 
qualify for this treatment (we can't see them OTG, but we map them anyway, as a 
public agency asserts their existence, though it hasn't signed them well).  
While routes like this are a relatively minor (lesser) concern about OTG, 
broader discussion continues here (in talk).  (I'm OK with that).  But lest my 
suggestion that we modify/soften OTG from a "hard rule" (which it isn't and 
cannot be) into a wishy-washy, too-ill-defined "guideline," please understand 
I'm stating OTG isn't a rule.  Rather, it is an excellent guideline to be 
followed where it can be and is, but it is a fact that it cannot be and is not 
always followed.  The particulars of how we better apply OTG going forward 
might be difficult to describe well and reach consensus upon, but we shouldn't 
let that deter us, even with disagreement.

Rather than get snarled in counter-examples, let's discuss how OTG isn't and 
can't be strictly followed in many cases.  It IS followed in the majority of 
cases, but in those corner cases where it isn't, because it can't be ("nothing" 
is OTG), must be realistically addressed, likely in our wiki where we state the 
"rule" today, though going forward much better state a "guideline".  I think we 
can get there, but it remains under discussion / construction.

SteveA
___
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

[onesime31]

Ok, je vais tenter avec cela. 
Pour le documenter, comment ça se passe? 


Merci! 

- Mail original -

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 < marc_marc_...@hotmail.com > 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

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

[Philippe Verdy]

Le mar. 11 févr. 2020 à 15:17, Rpnpif via Talk-fr 
a écrit :

> La possibilité de fusion des communes en France est très ancienne, elle
> a plus de 50 ans. Par exemple, certaines communes sont issues d'une
> campagne de fusion des années 1970. Ces dernières portent souvent le nom
> des deux communes séparées d'un trait d'union. Dans OSM, elles ne sont
> pas distinguées des communes non issues de fusion (ou plutôt, celles
> dont on se souvient qu'elles ne sont pas issues de fusion ; si on
> remonte très loin, au Moyen-Âge, ces communes non issues de fusion
> doivent être assez rares).


Effectivement puisque'au moyen-âge il n'y avait encore aucune "commune" en
France (en tout cas pas dans le sens civil de droit commun qu'on entend
aujourd'hui.
Les communes sont une création après la révolution française et l'abolition
des privilèges et de tous les anciens domaines seigneuriaux et
ecclésiastiques, et certains domaines pour des collèges de marchands (qui
avaient divers statuts très changeants selon les successions, invasions,
etc. seuls les bourgs semblaient délimités, les domaines ruraux n'avaient
pas de réelle frontière autre que naturelle et certains points de passage
sur les routes et chemins, plus ou moins défendus, selon la présence
militaire locale et le bon vouloir de la population locale et les moyens
des voyageurs).
Si on veut faire une cartographie des domaines seigneuriaux, cela va être
très compliqué car il va falloir gérer les dates dont bon nombre sont mal
connues. C'est un peu plus facile pour les domaines ecclésiastiques, bien
que leur usage pour le statut civil n'a pas suivi non plus les prétentions
seigneurales (Cela s'est compliqué avec les guerres de religion et nombreux
conflits de succession, mais aussi du fait des mobilisations et migrations
forcées de population par les seigneurs de passage sur "leurs" terres).
Les archives des communes ne remontent jamais avant la révolution, d'autant
plus que la toponymie est aussi incertaine et des tas de villages
différents ont été confondus.
___
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

[Mark Wagner]

On Sat, 8 Feb 2020 09:03:45 -0800
stevea  wrote:

> On Feb 8, 2020, at 2:58 AM, Rory McCann  wrote:
> > On 07.02.20 20:12, stevea wrote:  
> >> A well-known example is (national, other) boundaries, which
> >> frequently do not exist "on the ground,"  
> > National borders don't exist on the ground? huh? Have you ever
> > actually _crossed_ an international border? I assure you they exist
> > on the ground. From large infrastructure, to changes in the paint
> > colour on roads, one can nearly always *see* where a border is.  
> 
> I didn't say "always" (I said "frequently," though I was being
> parochial / local to me).  Between USA and Canada, for thousands (and
> thousands) of kilometers, the national border is entirely invisible.
> True, in places, it exists in an observable way (some stone markers,
> border crossings with paint-on-asphalt, even a fence or wall here or
> there), but I'd even say "mostly," the USA-Canada national border
> simply "isn't there:"  nothing on-the-ground, that is.

Have you actually been to the US-Canada border?  For thousands and
thousands of kilometers, it's really obvious:
https://upload.wikimedia.org/wikipedia/commons/a/aa/US-Canada_border_at_Crawford_State_Park_20130629.jpg

Even when it's not as obvious as in that photo, there are still
frequent boundary cairns.  And yes, they're mapped in OSM:
https://www.openstreetmap.org/node/1997617997

-- 
Mark


___
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]

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

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

[liste DOT girarsi AT posteo DOT eu]

> Il 10 febbraio 2020 21:21:08 CET, Alfredo Gattai  
> ha scritto:
>> Ciao lista,
>>
>> scusate in anticipo per la lungaggine ma e' necessaria.
>>

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.

Per esempio un possibile sentiero CAI 123 definito cai_scale EEA:F,
quindi un sentiero con tratti escursionistici e un tratto di ferrata,
oppure come può essere un caso, una tratta traversale tra due sentieri,
pura ferrata,non capisco a cosa serva la relazione via_ferrata, tolto
l'ovvio tratto intero come ferrata tra due sentieri CAI, o incrociando
lo stesso sentiero CAI.

Daq cosa parte l'idea di creare una relazione solo per le ferrate? per
avere una lista CAI unica su OSM di queste?

Per un tratto CAI 123 unico comprendente tutte le tratte, anche ferrata
si va di superroute?

Se ho compreso male la discussione me ne scuso.

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

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

[OSM-talk-be] Fwd: Discover the Programme of Open Belgium 2020

[joost schouppe]

Hi,

Time to register for one of the open highlights of Belgium. There's a
Valentine promotion going on right now :)
Contact board at osm.be if you can't afford the ticket.

There will also be a community day on Sunday with lots of OSM stuff; that
will be free.


-- Forwarded message -
Van: Astrid - Open Belgium 
Date: di 11 feb. 2020 om 11:55
Subject: Discover the Programme of Open Belgium 2020
To: 


[[Valentine offer]

PROGRAMME ONLINE NOW!


*More than 50 speakers and 40 session form the foundation of the Open
Belgium 2020 programme. We've got you covered!*

On 6 March over *50 national and international speakers* will bring you up
to speed with the latest trends on *Open Knowledge and Open Data.*

We prepared a *great mix of topics*, ranging from Open Banking to Open
Society, Open AI, Open Mobility, Open Education, Open Governance and Linked
Open Data...
Get Your Tickets


Sign Up Today

Get a head start on your favorite presentations and secure your ticket

now.
Use the promotional code *OpenBelgium20_Valentine* before 14 February
(11pm) and receive a 15% discount!
What´s included

Apart from a diverse lineup, your ticket also covers:
  -a refreshing lunch
  -warming coffee breaks
  -a closing reception
In short, plenty of opportunities to network with the open community!

*Same venue, next day*: in celebration of the global #OpenDataDay and as
part of Open Belgium 2020, we want to gather the open community on *Saturday
7 March* at the Civic Lab Summit. Register

here

for a free day of workshops!




*We look forward to seeing you at Open Belgium 2020,*

The Open Belgium team
[image: Facebook]

[image: Twitter]

[image: Website]


You are receiving this email because you attended Open Belgium 2019.

Want to change how you receive these emails?
You can update your preferences

or unsubscribe from this list
.







This email was sent to joost.schou...@gmail.com
*why did I get this?*

unsubscribe from this list

update subscription preferences

Open Knowledge Belgium · Kantersteen 12 · Brussels 1000 · Belgium

[image: Email Marketing Powered by Mailchimp]



-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

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

[deuzeffe]

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-GB] Freemap (free-map.org.uk) - potential shutdown

[Nick Whitelegg]

Hi,

As part of rationalising my server space and hosted projects, I am proposing 
shutting down my (very old) England and Wales footpath mapping site Freemap 
(free-map.org.uk).

This is basically because I no longer have the time to maintain and improve it 
and obviously incurs storage space and hosting costs, and I believe it is not 
used so much these days as it has been superseded by other projects.

Before I do so however, please let me know if you still use Freemap - if people 
are still using it, I will keep it up.

The underlying Freemap API, which powers several other projects including 
MapThePaths and Hikar, however, will remain up (albeit on a different server).

Thanks,
Nick



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

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

[leni]

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 ?

Cordialement

leni




(1) Ce tableau est appelé par 
https://wiki.openstreetmap.org/wiki/FR:Key:ref#Valeurs_du_projet_France


(2) ref:FR:geofer ; ref:FR:uic8 ; ref:FR:SIREN ; ref:FR:Orange_mobile ; 
ref:FR:ANFR ; ref:FR:SFR ; ref:FR:prix-carburants ; ref:ark


(3) ref:fr_illenoo ; ref:fr_tim ; ref:FR:STIF ; ref:IFOPT ; 
ref:FR:SMTC:STOPS ; ref:FR:CD38:STOPS ; ref:FR:STAR ; ref:FR:RATP ; 
ref:FR:aec31 ; ref:FR:Tisséo ; ref:=* ; ref:FR:commune ; 
ref:Metz Métropole


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

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

[Christian Quest]

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...



Le 11/02/2020 à 17:44, osm.sanspourr...@spamgourmet.com a écrit :

Bonjour Christian,

J'ai fait des essais assez exhaustifs afin d'avoir une modélisation de
place avec une zone pour confirmer tes dires : il faut ceinture et
bretelles, place sur la relation (logique) et place sur le nœud label
(ou admin_centre).

https://www.openstreetmap.org/relation/10060749

Oui ici ça n'avait pas de sens de dire admin_centre pour un lotissement,
mais c'est aussi valable pour admin_centre.

> je sais, je suis lourd
Pas toi, c'est le modèle qui est lourd.

Reste qu'on a des admin_centre de niveaux 8 et 9 pour les communes
déléguées et assimilées.

Si on force municipality comme type de place, on indique bien que la
valeur porte sur l'ensemble de la commune et non sur une des
communes/zone agglomérée. Heu, quoique : Audierne-Esquibien (niveau 8) a
pour admin centre l'admin centre d'Audierne (9).

Comment sait-on si la population du nœud Audierne concerne Audierne ou
Audierne-Esquibien ?

population:admin_level= 8 ou 9 pourrait le résoudre.

Est-ce qu'il y a mieux en stock dans vos méninges ?

Jean-Yvon

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

J'ai l'impression que le rendu osm.org ne prends en compte que les
noeuds place=*, pas les boundary.

Il fut une époque où il utilisait les deux, mais cela donnait des noms
en double.

Dans le rendu FR, j'ai une requête compliquée pour éviter ça... elle
prends le place=* en priorité (car mieux positionné) et le centroid du
boundary en second quand il n'y a pas de place pour un même nom.


Un noeud place=municipality avec un population pour prioriser quand on
manque de place (je sais, je suis lourd) permettrait de s'en sortir à
moindres frais.


Le 11/02/2020 à 15:32, marc marc a écrit :

Le 11.02.20 à 15:16, Rpnpif via Talk-fr a écrit :

ne pas les repérer par un nœud place=* contrairement aux communes
d'avant 2010

je pense qu'il y a une erreur de modélisation dans ta vision
place=town/city représente un village/ville, peu importe que la commune
où il se trouve n'ai jamais fusionné ou fusionnée jadis ou récemment.
un polygone ou une relation boundary administrative admin_level=8
représente une commune, peu importe qu'elle ai jamais fusionné ou
fusionnée jadis ou récemment.
il n'y a aucune différence de traitement selon leur origine.

il se fait qu'il y a des villages/villes qui portent le même nom que la
commune et d'autre pas, c'est le choix des intéressés de garder
(fréquent en cas de fusion gros avec petit) ou de changer (fréquent en
cas de fusion entre +- égaux en taille) le nom d'une commune lors de la
fusion.

cela ne va pas du tout de créer un faux place=town/city juste pour 
faire

apparaître le nom d'une commune parce que invisible sur un rendu donné.
cela ne va pas mieux de créer un lieu-dit inhabité pour forcer
un rendu a afficher le nom d'une commune n'ayant pas de lieu habité
avec le même nom.

si tu veux vraiment créer un objet place=* dupliqué ce serrait
place=municipality qui serrait lui aussi tout aussi invisible par le
rendu que tu critiques (et je partage ton avis sur le côté pas génial
de ne pas voir les communes de manière + claire qu'un nom à la
frontière).

une piste de solution : rendre les (toutes) communes + visible sur le
rendu osm-fr pour ensuite en discuter sur le rendu osm-carto
___
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


--
Christian Quest - OpenStreetMap France


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

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

[onesime31]

Bonsoir, 


Merci pour vos échanges... la date de la session de cartoparty approche 
(vendredi)... et je suis toujours dans le flou. 


Comme je l'ai évoqué, la commande est de faire: 
- une mise à jour des panneaux de villes et villages, 
- renseigner le EB10 ou EB20 (entrée ou sortie de village), 
- renseigner si les 2 panneaux sont au même niveau, 

- renseigner si le panneau est zérophyto ou non => si le poteau est ancré dans 
le sol directement ou s'il y a un carré de béton au pied (qui ne nécessite pas 
de désherbant). 


C'est une cartoparty avec une classe de géomaticien, et pour faire découvrir 
OSM et l'enrichir par la même occasion, on se base sur OSM pour répondre à la 
commande qui nous est faite (en général, ça se passe en classe en se basant sur 
des ressources libres telles que Mapillary, OpenStreetCam, etc.). 


Là, j'avoue que les différents échanges font que je n'y voit toujours pas plus 
claire. Je suis entrain de préparer les consignes avec les tags, etc. 

- on est d'accord pour utiliser traffic_sign=city_limit , puis éventuellement 
name= pour le nom du village. 
- pour le sens, par contre, on a le choix 

- entre traffic_sign:forward= city_limit et traffic_sign:backward = city_limit 

- OU traffic_sign=city_limit,FR:EB10 et traffic_sign=city_limit,FR:EB20 
- pour le poteau, si je comprends bien, il faut utiliser support=pole dans tous 
les cas si le panneau est sur un poteau... par contre, il n'y a pas trop de 
solution pour renseigner si le poteau est sur du béton ou non? 


Il y aurait une 30ne d'élèves pour bosser dessus sur une journée... et ce 
serait dommage qu'OSM ne profite pas de cette aubaine? (renseigner OSM est du 
bonus, on nous demande juste un shapefile avec les infos). 
Concernant le département, c'est le Gers, donc on est pas trop sur la 
problématique de passer d'une agglo à l'autre avec les histoires de vitesse, on 
est vraiment dans un contexte rural. 


Merci, bonne fin de journée, 


Onésime 





- Mail original -

De: "Christian Quest"  
À: talk-fr@openstreetmap.org 
Envoyé: Mardi 11 Février 2020 17:00:25 
Objet: Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & 
villages 

Le 11/02/2020 à 14:33, 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... 

+1000 ! 

KISS 

-- 
Christian Quest - OpenStreetMap France 


___ 
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] Nouvelles communes françaises issues de fusion et OSM

[osm . sanspourriel]

Bonjour Christian,

J'ai fait des essais assez exhaustifs afin d'avoir une modélisation de
place avec une zone pour confirmer tes dires : il faut ceinture et
bretelles, place sur la relation (logique) et place sur le nœud label
(ou admin_centre).

https://www.openstreetmap.org/relation/10060749

Oui ici ça n'avait pas de sens de dire admin_centre pour un lotissement,
mais c'est aussi valable pour admin_centre.

> je sais, je suis lourd
Pas toi, c'est le modèle qui est lourd.

Reste qu'on a des admin_centre de niveaux 8 et 9 pour les communes
déléguées et assimilées.

Si on force municipality comme type de place, on indique bien que la
valeur porte sur l'ensemble de la commune et non sur une des
communes/zone agglomérée. Heu, quoique : Audierne-Esquibien (niveau 8) a
pour admin centre l'admin centre d'Audierne (9).

Comment sait-on si la population du nœud Audierne concerne Audierne ou
Audierne-Esquibien ?

population:admin_level= 8 ou 9 pourrait le résoudre.

Est-ce qu'il y a mieux en stock dans vos méninges ?

Jean-Yvon

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

J'ai l'impression que le rendu osm.org ne prends en compte que les
noeuds place=*, pas les boundary.

Il fut une époque où il utilisait les deux, mais cela donnait des noms
en double.

Dans le rendu FR, j'ai une requête compliquée pour éviter ça... elle
prends le place=* en priorité (car mieux positionné) et le centroid du
boundary en second quand il n'y a pas de place pour un même nom.


Un noeud place=municipality avec un population pour prioriser quand on
manque de place (je sais, je suis lourd) permettrait de s'en sortir à
moindres frais.


Le 11/02/2020 à 15:32, marc marc a écrit :

Le 11.02.20 à 15:16, Rpnpif via Talk-fr a écrit :

ne pas les repérer par un nœud place=* contrairement aux communes
d'avant 2010

je pense qu'il y a une erreur de modélisation dans ta vision
place=town/city représente un village/ville, peu importe que la commune
où il se trouve n'ai jamais fusionné ou fusionnée jadis ou récemment.
un polygone ou une relation boundary administrative admin_level=8
représente une commune, peu importe qu'elle ai jamais fusionné ou
fusionnée jadis ou récemment.
il n'y a aucune différence de traitement selon leur origine.

il se fait qu'il y a des villages/villes qui portent le même nom que la
commune et d'autre pas, c'est le choix des intéressés de garder
(fréquent en cas de fusion gros avec petit) ou de changer (fréquent en
cas de fusion entre +- égaux en taille) le nom d'une commune lors de la
fusion.

cela ne va pas du tout de créer un faux place=town/city juste pour faire
apparaître le nom d'une commune parce que invisible sur un rendu donné.
cela ne va pas mieux de créer un lieu-dit inhabité pour forcer
un rendu a afficher le nom d'une commune n'ayant pas de lieu habité
avec le même nom.

si tu veux vraiment créer un objet place=* dupliqué ce serrait
place=municipality qui serrait lui aussi tout aussi invisible par le
rendu que tu critiques (et je partage ton avis sur le côté pas génial
de ne pas voir les communes de manière + claire qu'un nom à la
frontière).

une piste de solution : rendre les (toutes) communes + visible sur le
rendu osm-fr pour ensuite en discuter sur le rendu osm-carto
___
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-ie] OSM at LoveDataWeek 2020 - Maynooth University

[Jeffrey Roe]

It is used to show real-time air quality data.

https://sensor.community/

Jeffrey Roe,
www.tog.ie

On Tue, Feb 11, 2020 at 12:19 PM Heikki Vesanto
 wrote:
>
> Hi Peter,
>
> Sounds great.
>
> Andrei Kashcha has created some cool tools around OSM.
>
> For example a tool to generate the road network for any location:
> https://anvaka.github.io/city-roads/
>
> That is pure OSM.
>
> He also has a ridge plot map generator:
> https://anvaka.github.io/peak-map/
>
> Just OSM for the mapping, it uses MapBox elevation API for the plotting.
> Still pretty cool.
>
>
> -Heikki
>
>
> On Sun, Feb 9, 2020 at 1:59 PM Donal Hunt  wrote:
>
> > I'm the sure the mobility forum and cycling campaign would be happy for a
> > mention about the Cork cycling map that was launched last year. The base
> > map used OpenStreetMap data before the additional landmarks and highlighted
> > routes were added.
> >
> > https://transportandmobilityforum.com/cork-cycle-map/
> >
> > Donal
> >
> > On Sat, 8 Feb 2020 at 14:51, Peter Mooney  wrote:
> >
> > > Hello everyone,
> > >
> > > I'm giving a general overview talk about OpenStreetMap in Maynooth
> > > University next week, as part of Love Data Week 2020. Details are here
> > [1].
> > >
> > > I only have an hour so I want to show attendees what kinds of
> > applications
> > > OpenStreetMap is being used for in Ireland and beyond. This will include
> > > quick examples of downloading data, using Turbo Overpass online, and a
> > very
> > > basic map using Leaflet. I'll be showing the work of OSM IE (example the
> > > recent Kilkenny work), Townlands, Hieki's visualisations, etc.
> > >
> > > If you have any other really interesting examples of OSM use which would
> > be
> > > good for a general audience, please let me know and I'd be delighted to
> > > include it.
> > >
> > > I will make my slides openly available in ODP format afterwards, if they
> > > are useful for someone else.
> > >
> > > With every best wish,
> > >
> > > Peter
> > >
> > > [1] https://www.maynoothuniversity.ie/library/events/love-data-week-2020
> > > ___
> > > Talk-ie mailing list
> > > Talk-ie@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-ie
> > >
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
> >
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie

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

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

[Christian Quest]

J'ai l'impression que le rendu osm.org ne prends en compte que les 
noeuds place=*, pas les boundary.


Il fut une époque où il utilisait les deux, mais cela donnait des noms 
en double.


Dans le rendu FR, j'ai une requête compliquée pour éviter ça... elle 
prends le place=* en priorité (car mieux positionné) et le centroid du 
boundary en second quand il n'y a pas de place pour un même nom.



Un noeud place=municipality avec un population pour prioriser quand on 
manque de place (je sais, je suis lourd) permettrait de s'en sortir à 
moindres frais.



Le 11/02/2020 à 15:32, marc marc a écrit :

Le 11.02.20 à 15:16, Rpnpif via Talk-fr a écrit :

ne pas les repérer par un nœud place=* contrairement aux communes
d'avant 2010

je pense qu'il y a une erreur de modélisation dans ta vision
place=town/city représente un village/ville, peu importe que la commune
où il se trouve n'ai jamais fusionné ou fusionnée jadis ou récemment.
un polygone ou une relation boundary administrative admin_level=8
représente une commune, peu importe qu'elle ai jamais fusionné ou
fusionnée jadis ou récemment.
il n'y a aucune différence de traitement selon leur origine.

il se fait qu'il y a des villages/villes qui portent le même nom que la
commune et d'autre pas, c'est le choix des intéressés de garder
(fréquent en cas de fusion gros avec petit) ou de changer (fréquent en
cas de fusion entre +- égaux en taille) le nom d'une commune lors de la
fusion.

cela ne va pas du tout de créer un faux place=town/city juste pour faire
apparaître le nom d'une commune parce que invisible sur un rendu donné.
cela ne va pas mieux de créer un lieu-dit inhabité pour forcer
un rendu a afficher le nom d'une commune n'ayant pas de lieu habité
avec le même nom.

si tu veux vraiment créer un objet place=* dupliqué ce serrait
place=municipality qui serrait lui aussi tout aussi invisible par le
rendu que tu critiques (et je partage ton avis sur le côté pas génial
de ne pas voir les communes de manière + claire qu'un nom à la frontière).

une piste de solution : rendre les (toutes) communes + visible sur le
rendu osm-fr pour ensuite en discuter sur le rendu osm-carto
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

[Christian Quest]

Vous connaissez Lyas ? charmante bourgade de 601 âmes, désormais mise en 
avant sur le rendu FR dès le zoom 6


Tout comme Acon... 468 habitants, ou Y... 92 habitants

Voilà :(


J'accepte volontiers la PR pour corriger ça dans le rendu...

--
Christian Quest - OpenStreetMap France


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

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

[Christian Quest]

Le 11/02/2020 à 14:33, 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...


+1000 !

KISS

--
Christian Quest - OpenStreetMap France


___
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]

penses à le décrire sur le wiki en Anglais et Français au moins

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
>


-- 
Cordialement,
Jérôme Seigneuret
___
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 ?

[Shohreh]

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

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

[Jérôme Seigneuret]

*tourism *est plus large que l'on peut l'entendre. les panneaux de
direction sont aussi utilisé avec cette clé

Le mar. 11 févr. 2020 à 16:20, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> bon ben tu t'es répondu tout seul ;-)
>
> Le mar. 11 févr. 2020 à 16:17, Shohreh  a écrit :
>
>> Shohreh wrote
>> > Quid de man_made=surveillance avec board_type=surveillance +
>> > information=board ?
>>
>> Mauvaise idée, puisque c'est pour marquer la caméra, pas un panneau pour
>> indiquer une zone :-/
>>
>>
>>
>> --
>> 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
>>
>
>
> --
> Cordialement,
> Jérôme Seigneuret
>


-- 
Cordialement,
Jérôme Seigneuret
___
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]

bon ben tu t'es répondu tout seul ;-)

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

> Shohreh wrote
> > Quid de man_made=surveillance avec board_type=surveillance +
> > information=board ?
>
> Mauvaise idée, puisque c'est pour marquer la caméra, pas un panneau pour
> indiquer une zone :-/
>
>
>
> --
> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
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 ?

[Shohreh]

Shohreh wrote
> Quid de man_made=surveillance avec board_type=surveillance +
> information=board ?

Mauvaise idée, puisque c'est pour marquer la caméra, pas un panneau pour
indiquer une zone :-/



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

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

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

[Shohreh]

Merci pour l'idée (et désolé pour le doublon : le message n'apparaissait pas
dans les archives et sur Nabble).

tourism=information
information=board
board_type=surveillance

Difficile quand même d'utiliser un panneau de tourisme pour ce genre d'info.

Quid de man_made=surveillance avec board_type=surveillance +
information=board ?

https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dsurveillance



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

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

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

[Jérôme Seigneuret]

non information est un sous élément de tourism donc j'ai mis à chaud met
pas par hasard

Description
Clé pour décrire de façon complète les panneaux d'informations
touristiques [image:
Edit or translate this description.]

*Groupe:* Tourisme

Utilisé pour ces éléments


[image: peut être utilisé sur des nœuds]
[image: ne devrait pas
être utilisé sur des chemins]
[image: peut être utilisé
sur des zones] [image: ne
devrait pas être utilisé sur des relations]

Nécessite

   - tourism =
   information
   

Combinaisons utiles

   - tourism =
   information
   


tourism=information
information=bord
bord_type=surveillance


Le mar. 11 févr. 2020 à 15:25, Rpnpif via Talk-fr 
a écrit :

> Le 11/02/2020 à 10:37, Jérôme Seigneuret a écrit :
>
>
>>
>> à chaud, j'aurais créé traffic_sign=surveillance
>> ___
>>
> Pour moi c'est pas en lien avec le traffic
>
> A chaud ;-)
> tourism=information
> information=bord
> bord_type=surveillance
>
>
> Tu veux dire :
>
> Information=board
> board_type=surveillance
>
> ;)
>
> --
> Rpnpif
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[marc marc]

Le 11.02.20 à 15:16, Rpnpif via Talk-fr a écrit :
> ne pas les repérer par un nœud place=* contrairement aux communes
> d'avant 2010

je pense qu'il y a une erreur de modélisation dans ta vision
place=town/city représente un village/ville, peu importe que la commune
où il se trouve n'ai jamais fusionné ou fusionnée jadis ou récemment.
un polygone ou une relation boundary administrative admin_level=8
représente une commune, peu importe qu'elle ai jamais fusionné ou
fusionnée jadis ou récemment.
il n'y a aucune différence de traitement selon leur origine.

il se fait qu'il y a des villages/villes qui portent le même nom que la
commune et d'autre pas, c'est le choix des intéressés de garder
(fréquent en cas de fusion gros avec petit) ou de changer (fréquent en
cas de fusion entre +- égaux en taille) le nom d'une commune lors de la
fusion.

cela ne va pas du tout de créer un faux place=town/city juste pour faire
apparaître le nom d'une commune parce que invisible sur un rendu donné.
cela ne va pas mieux de créer un lieu-dit inhabité pour forcer
un rendu a afficher le nom d'une commune n'ayant pas de lieu habité
avec le même nom.

si tu veux vraiment créer un objet place=* dupliqué ce serrait
place=municipality qui serrait lui aussi tout aussi invisible par le
rendu que tu critiques (et je partage ton avis sur le côté pas génial
de ne pas voir les communes de manière + claire qu'un nom à la frontière).

une piste de solution : rendre les (toutes) communes + visible sur le
rendu osm-fr pour ensuite en discuter sur le rendu osm-carto
___
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 ?

[Rpnpif via Talk-fr]

Le 11/02/2020 à 10:37, Jérôme Seigneuret a écrit :




à chaud, j'aurais créé traffic_sign=surveillance
___

Pour moi c'est pas en lien avec le traffic

A chaud ;-)
tourism=information
information=bord
bord_type=surveillance


Tu veux dire :

Information=board
board_type=surveillance

;)

--
Rpnpif

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

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

[Rpnpif via Talk-fr]

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.


La possibilité de fusion des communes en France est très ancienne, elle 
a plus de 50 ans. Par exemple, certaines communes sont issues d'une 
campagne de fusion des années 1970. Ces dernières portent souvent le nom 
des deux communes séparées d'un trait d'union. Dans OSM, elles ne sont 
pas distinguées des communes non issues de fusion (ou plutôt, celles 
dont on se souvient qu'elles ne sont pas issues de fusion ; si on 
remonte très loin, au Moyen-Âge, ces communes non issues de fusion 
doivent être assez rares).


De façon que je considère arbitraire, les communes issues de fusion 
d'après 2010 (pourquoi ne pas prendre celles avant 2010 ?) , il a été 
décidé ici même de traiter à part les communes nouvelles en ne les 
enregistrant que par leur frontière et sous forme de relation avec leurs 
anciennes communes membres et leur admin_centre. Il a aussi été décidé 
de ne pas les repérer par un nœud place=* contrairement aux communes 
d'avant 2010 même issues de fusion (donc beaucoup comme on l'a vu).


La conséquence la plus visible est que ces communes sont totalement 
invisibles dans le rendu officiel osm.org qui n'affiche pas le nom des 
zones englobées par une frontière sans place=*.  Il y a pourtant 
d'autres limites dont le nom est affiché comme les forêts, etc. 
Geoportail de l'IGN affiche bien, lui, ces nouvelles communes.


On répond que les nouvelles communes ne sont que des délimitations 
administratives qui n'ont pas vocation à être des lieux-dits. Cette 
opinion est contestable car c'est pourtant comme cela que l'on note les 
anciennes communes issues ou non de fusion. De plus dans l'esprit du 
législateur, les nouvelles communes issues de fusions récentes ont 
vocation à fonctionner comme les autres communes en intégrant 
complètement les anciennes qui ne deviennent que des sortes de quartiers 
ou arrondissements. Ces anciennes communes peuvent être des villages et 
parfois des petites villes (plus de 1 habitants aux abords d'une 
grande agglomération).


Par exemple, une commune classique non issue de fusion récente comporte 
souvent un bourg qui est appelé Le Bourg par les habitants et est 
rarement repéré par ce nom dans Osm.org (alors que BANO peut le 
marquer). En général, la mairie décide de noter sur les panneaux 
d'entrées du bourg le nom de la commune. Donc la commune est aussi un 
lieu-dit qui devrait être noté par place=* au niveau du bourg ou de 
l'agglomération principale. Dans le cas d'une commune issue de fusion 
récente, certaines mairies n'affichent que le nom de la commune issue de 
fusion et pas l'ancienne. D'autres affichent le nom de l'ancienne 
commune avec mention du nom de la nouvelle dessous. Évidemment, quand le 
nom de la commune issue de la fusion est le même que celle de celui de 
la commune admin_centre, le problème est plus simple.


Les habitants et autres partenaires des nouvelles communes récentes font 
de moins en moins la distinction avec le fonctionnement des communes non 
fusionnées récemment que ce soit pour leurs relations avec la mairie, la 
Poste, etc. (bien sûr après un temps d'adaptation plus ou moins facile 
et plus ou moins heureux). Ils ont donc de plus en plus besoin de 
repérer leur commune nouvelle sur une carte.


En conséquence de ce que j'écris ci-dessus, ma proposition est la suivante :

Traiter les nouvelles communes comme les anciennes avec une relation 
frontière (boundary) et un nœud place=* mis aux abords de l'admin-centre 
ou bien vers le centre de la commune.


Garder le nœud place=* et la relation frontière (boundary) des anciennes 
communes comme on le fait déjà pour les place=village des lieux-dits 
d'agglomération de plus de 200 et de moins de 1 habitants à 
l'intérieur d'une commune « non fusionnée » récemment.


Cette proposition permet de simplifier les contributions ainsi que les 
moteurs de rendus.


--
Rpnpif


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

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

[Jérôme Seigneuret]

>
> j'ai visiblement mal formulé ma remarque :
> FAIT: quand on passe de "hors zone urbaine" à "zone urbaine" en
> croissant donc un panneau EB10 dans un sens et un panneau EB20 dans
> l'autre sens, cela se MODELISE dans osm par traffic_sign=city_limit
> QUESTION : si on modélise l'entrée sur un way bi-directionnel,
> a-t-on besoin de dire que dans le sens inverse c'est une sortie ?
>
Non sauf si tu modélise le matériel en tant que tel. Donc on peut définir :
un niveau 1 de précision en lien avec juste l'information routière et son
découpage simple
on considère que le cas par défaut c'est
traffic_sign=city_limit+ direction=forward
traffic_sign:forward=FR:EB10[agglo];traffic_sign:backward=FR:EB20[agglo]
Avec 1 noeud à la limite des zones


>
> On pourrait réserver ce niveau de précision au cas des voie en
> sens-unique puisque dans ce cas (seulement ?) le panneau entrée n'est pas

dans ce cas en effet tu as une notion de sortie
en entrée
traffic_sign:forward=FR:EB10[agglo];
en sortie
traffic_sign:backward=FR:EB20[agglo]

Dans les autres (99% ?) cas, c'est une complexification dont
> je ne vois l'information supplémentaire qu'elle apporte.
>
Toi peut être mais on me modélise pas tous pour les même chose et certains
pas pour le routing

@marc il suffirait de limiter le niveau de détail (ou d'abstraction) que
l'on souhaite c'est aussi ça une base... Mais c'est pas fait (tous du moins
pas jusqu'a un certain niveau)
On voit ça sur l'électricité ou l'on atteint le niveau de précision d'une
base métier

D'où la multiplicité des méthodes et niveaux détails sur les données.

Pour revenir au niveau des support:
Pour éviter de renter dans l'usine à gaz on prend l'objet en tant que tel.
L'objet que l'on décrit est matérialisé sous forme de point est situer où?
sur un mur ou au sol? si tu veux aller plus loin dans ce cas on va dans du
commentaire ( regrouper sur un poteau)
On doit pouvoir comme on le disait plus haut trouver certains modèles et
les décrire assez bien pour que des outils puissent exploiter les données
et que des contributeurs puissent fournir des informations.
Si l'on commence à avoir des imbrications d'un même éléments (chose que je
ne pensais pas accepté) ça va aller super loin. Et plus loin jusqu'à
présent s'était ailleurs

-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition de Hack Weekend à Toulouse (Avril)

[Frédéric Rodrigo]

J'ai créer un framadate pour trouver le weekend qui convient le mieux

https://framadate.org/lugSTfQkmgibtAL9

l'idée est d’arrêter une date assez vite.

Frédéric


Le 07/02/2020 à 22:29, Vincent Privat a écrit :

Très bon choix de ville, je viens ! :D

Le ven. 7 févr. 2020 à 16:38, Christine Karch > a écrit :


Idée géniale :)

On pourrait demander l'Asso de supporter le coût du transport ...


Am 07.02.20 um 16:28 schrieb PanierAvide:
> Bonjour,
>
> Ce serait sympa en effet, à voir selon la date et le coût du
transport
> car Rennes c'est pas à côté.
>
> Cordialement,
>
> Adrien P.
>
> Le 07/02/2020 à 15:36, Vincent de Château-Thierry a écrit :
>> Bonjour,
>>
>>> De: "Frédéric Rodrigo" mailto:fred.rodr...@gmail.com>>
>>>
>>> Avec mon employeur, Makina Corpus, je propose d'organiser une Hack
>>> Weekend à Toulouse, sur le modèle de ce que fait par exemple
>>> Geofabrik.
>>> Il n'y a pas encore de date, mais l'idée est de le faire vers
avril.
>>> J'ai commencé à préparer une page sur le wiki pour cela:
>>>
https://wiki.openstreetmap.org/wiki/Toulouse_Hack_Weekend_April_2020
>>>
>>> J'aurais aimé avoir vos retours sur cette proposition et notamment
>>> pour
>>> choisir une date.
>> Bonne idée ça :)
>>
>> Tu lances un https://framadate.org/ pour trouver le bon WE ?
>>
>> vincent
>>
>> ___
>> 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




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

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

[marc marc]

Le 11.02.20 à 14:00, Florimond Berthoux a écrit :
> 
> 
> Le mar. 11 févr. 2020 à 00:18, marc marc a écrit :
> 
> > donc une alternative et une meilleure manière de le noter est la
> suivante :
> > - traffic_sign=city_limit,FR:EB20.
> 
> je comprend pas ce que tu veux dire avec cette totologie.
> une limite urbaine est un panneau EB20 et vice-versa.
> a-t-on besoin de dire que si on suit le chemin inverse d'une entrée
> c'est une sortie ? cela me semble lourd pour un gain qui m’échappe.
> 
> 
> city_limit c’est FR:EB10 *ou* EB20, le city_limit ne définit pas si
> c’est une entrée ou une sortie
> (oui city_limit est pas top comme tag)

j'ai visiblement mal formulé ma remarque :
FAIT: quand on passe de "hors zone urbaine" à "zone urbaine" en
croissant donc un panneau EB10 dans un sens et un panneau EB20 dans
l'autre sens, cela se MODELISE dans osm par traffic_sign=city_limit
QUESTION : si on modélise l'entrée sur un way bi-directionnel,
a-t-on besoin de dire que dans le sens inverse c'est une sortie ?

On pourrait réserver ce niveau de précision au cas des voie en
sens-unique puisque dans ce cas (seulement ?) le panneau entrée n'est pas
sur le même way que celui de sortie.
Dans les autres (99% ?) cas, c'est une complexification dont
je ne vois l'information supplémentaire qu'elle apporte.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[marc marc]

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

Re: [Diversity-talk] Community track at SOTM

[Christine Karch]

No worry about the weekend, this is just the deadline for the
scholarships. The call for participations ends 20 February :)

Am 11.02.20 um 13:42 schrieb Heather Leson:
> Thanks for the question, Christine. We were hoping to string together 3
> sessions for a morning. This way we can build on how we might progress
> on  community. My draft suggestion is to consider some of the topics
> from fosdem, the osm swot and the community survey. Next I will start a
> collaborative draft. 
> 
> In this draft, we will shape the themes and formats.
> 
> I am on work mission this week so I wont be able to tackle this until
> the weekend. The good news is that ive been contacted offlist by some
> allies who are keen to have productive make sessions
> 
> Thanks again 
> 
> Heather 
> 
> On Tue, 11 Feb 2020, 15:31 Christine Karch,  > wrote:
> 
> Hi, sounds like a good idea. Thank you for organizing that! Is the space
> of a 90 minutes panel or extended talk enough for that kind of session?
> Or do you need something more special? I would recommend to add this in
> the "notes" section during the submission!
> 
> Am 09.02.20 um 06:20 schrieb Heather Leson:
> > Hi I chatted briefly with Trudy. Who would like to help me curate a
> > track on community for SOTM?
> >
> > Last weekend I went to FOSDEM. There were some great talks that relate
> > to our work - I curated a list (videos and slides are online)
> >
> > https://www.openstreetmap.org/user/Heather%20Leson/diary/392119
> >
> > heather
> >
> > Heather Leson
> > heatherle...@gmail.com 
> >
> > Twitter/skype: HeatherLeson
> > Blog: textontechs.com 
> 
> >
> > ___
> > 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

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

[Florimond Berthoux]

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.

(support:pole:support:ground:support=earth
support:pole:support:ground:support:earth:support=space
:D)

Le mar. 11 févr. 2020 à 00:15, marc marc  a
écrit :

> Le 10.02.20 à 22:23, osm.sanspourr...@spamgourmet.com a écrit :
> > pour préciser l'ancrage :
> > pole_mount=ground ou concrete_slab  à la manière de
> > https://wiki.openstreetmap.org/wiki/Key:lamp_mount
>
>
> lamp_mount est une horreur à ne pas suivre.
> 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

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

[Florimond Berthoux]

Le mar. 11 févr. 2020 à 00:18, marc marc  a
écrit :

> > donc une alternative et une meilleure manière de le noter est la
> suivante :
> > - traffic_sign=city_limit,FR:EB20.
>
> je comprend pas ce que tu veux dire avec cette totologie.
> une limite urbaine est un panneau EB20 et vice-versa.
> a-t-on besoin de dire que si on suit le chemin inverse d'une entrée
> c'est une sortie ? cela me semble lourd pour un gain qui m’échappe.
>

city_limit c’est FR:EB10 *ou* EB20, le city_limit ne définit pas si c’est
une entrée ou une sortie
(oui city_limit est pas top comme tag)

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

Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

[Santens Seppe]

That’s indeed the (fun) challenge ☺
Luckily, there are already some good sources available. Two I’ve used:

·   for some of the municipalities, Wikipedia offers a lot of information, 
see e.g. https://fr.wikipedia.org/wiki/Liste_des_rues_de_Schaerbeek

·   http://www.irismonument.be often has good info, e.g. 
http://www.irismonument.be/nl.Elsene.Francois_Stroobantstraat.html 
http://www.irismonument.be/fr.Ixelles.Rue_Francois_Stroobant.html (you can just 
enter the street name in their search box)

Seppe

Van: Jonathan Beliën [mailto:l...@jbelien.be]
Verzonden: dinsdag 11 februari 2020 12:23
Aan: talk-be@openstreetmap.org
Onderwerp: Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

Yes, that's the big question mark for the event !
We'll hope to attract people with such knowledge and/or hope to find the 
information online somehow !

That's one of the reason we decided not to edit OpenStreetMap directly during 
the event !

Jonathan Beliën


Mar 11 févr 2020, à 12:18, Jo a écrit :
I think the hardest part is figuring out what the name stands for if it is a 
former maire of the city or commune. Especially if we only have an initial for 
the first name. Sometimes it is possible to find this information on the 
internet, often it isn't.

Do we have a way to look into the city's archives?

Jo



On Tue, Feb 11, 2020 at 11:07 AM Jonathan Beliën 
mailto:l...@jbelien.be>> wrote:

Given this workflow, I wonder whether we can drop the focus on Wikipedia (to 
save work/time): 1) If there is an existing Wikipedia page, it will probably 
already be linked to the corresponding Wikidata item. 2) If we put a Wikidata 
tag on a street in OSM, I personally see no reason to add a Wikipedia tag as 
well, as the Wikipedia page can be found through the Wikidata item (I now not 
all data consumers will work like that, but I feel they should be educated to 
do so ☺ )

Yes, I thought about adding the `wikipedia` tag if there is a Wikipedia page 
but no wikidata "page" but we could indeed add the `wikipedia` tag even if we 
have the `wikidata` tag !

I guess the link between OSM street and Wikidata item for that street will be 
done beforehand (automagically)? In that case, we could really focus on the 
people behind the street names and only fill in the name:etymology:wikidata tag 
in OSM and/or the ‘named after’ statement in Wikidata.

Indeed, automagically but (very) carefully !
Exact process is not defined yet, I'll consult all of you to find the best way 
to do that properly !
Addition of the tags in OSM will be done no matter what AFTER the event but the 
participant will have access to that information to help them in their research 
of course.

I suppose the participants of the workshop will also have an option to indicate 
1) is this street named after a person (y/n) 2) which gender does the person 
have (m/f/don’t know)

You suppose correctly !
We'll get all those information during the event !
But the final process will get the gender from the wikidata "page" (if there is 
a wikidata "page" for every person that have a street with their name).

Thanks for the feedback !

Jonathan Beliën


Mar 11 févr 2020, à 10:56, Santens Seppe a écrit :

Hi Jonathan,



Workflow sounds good!

If I may, a few remarks:

•   Given this workflow, I wonder whether we can drop the focus on 
Wikipedia (to save work/time): 1) If there is an existing Wikipedia page, it 
will probably already be linked to the corresponding Wikidata item. 2) If we 
put a Wikidata tag on a street in OSM, I personally see no reason to add a 
Wikipedia tag as well, as the Wikipedia page can be found through the Wikidata 
item (I now not all data consumers will work like that, but I feel they should 
be educated to do so ☺ )

•   I guess the link between OSM street and Wikidata item for that street 
will be done beforehand (automagically)? In that case, we could really focus on 
the people behind the street names and only fill in the name:etymology:wikidata 
tag in OSM and/or the ‘named after’ statement in Wikidata.

•   I suppose the participants of the workshop will also have an option to 
indicate 1) is this street named after a person (y/n) 2) which gender does the 
person have (m/f/don’t know)



Cheers,



Seppe





Van: Jonathan Beliën [mailto:l...@jbelien.be]
Verzonden: dinsdag 11 februari 2020 10:16
Aan: talk-be@openstreetmap.org
Onderwerp: Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data



Hello everyone,



I just find out about this discussion and realize we are currently doing the 
work twice !



The initial (and main) goal of the project is indeed to link streets in 
Brussels from OpenStreetMap with the wikidata "page" of the person present in 
the streetname !




BUT we got in contact with Romain (Wikimedia Belgium) and he told us that he is 
working on creating a wikidata "page" for all the streets in Brussels and that 
his works is 

Re: [Diversity-talk] Community track at SOTM

[Heather Leson]

Thanks for the question, Christine. We were hoping to string together 3
sessions for a morning. This way we can build on how we might progress on
community. My draft suggestion is to consider some of the topics from
fosdem, the osm swot and the community survey. Next I will start a
collaborative draft.

In this draft, we will shape the themes and formats.

I am on work mission this week so I wont be able to tackle this until the
weekend. The good news is that ive been contacted offlist by some allies
who are keen to have productive make sessions

Thanks again

Heather

On Tue, 11 Feb 2020, 15:31 Christine Karch,  wrote:

> Hi, sounds like a good idea. Thank you for organizing that! Is the space
> of a 90 minutes panel or extended talk enough for that kind of session?
> Or do you need something more special? I would recommend to add this in
> the "notes" section during the submission!
>
> Am 09.02.20 um 06:20 schrieb Heather Leson:
> > Hi I chatted briefly with Trudy. Who would like to help me curate a
> > track on community for SOTM?
> >
> > Last weekend I went to FOSDEM. There were some great talks that relate
> > to our work - I curated a list (videos and slides are online)
> >
> > https://www.openstreetmap.org/user/Heather%20Leson/diary/392119
> >
> > heather
> >
> > Heather Leson
> > heatherle...@gmail.com 
> > Twitter/skype: HeatherLeson
> > Blog: textontechs.com 
> >
> > ___
> > 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

Re: [Diversity-talk] Community track at SOTM

[Christine Karch]

Hi, sounds like a good idea. Thank you for organizing that! Is the space
of a 90 minutes panel or extended talk enough for that kind of session?
Or do you need something more special? I would recommend to add this in
the "notes" section during the submission!

Am 09.02.20 um 06:20 schrieb Heather Leson:
> Hi I chatted briefly with Trudy. Who would like to help me curate a
> track on community for SOTM?
> 
> Last weekend I went to FOSDEM. There were some great talks that relate
> to our work - I curated a list (videos and slides are online)
> 
> https://www.openstreetmap.org/user/Heather%20Leson/diary/392119
> 
> heather
> 
> Heather Leson
> heatherle...@gmail.com 
> Twitter/skype: HeatherLeson
> Blog: textontechs.com 
> 
> ___
> 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

Re: [OSM-talk-ie] OSM at LoveDataWeek 2020 - Maynooth University

[Heikki Vesanto]

Hi Peter,

Sounds great.

Andrei Kashcha has created some cool tools around OSM.

For example a tool to generate the road network for any location:
https://anvaka.github.io/city-roads/

That is pure OSM.

He also has a ridge plot map generator:
https://anvaka.github.io/peak-map/

Just OSM for the mapping, it uses MapBox elevation API for the plotting.
Still pretty cool.


-Heikki


On Sun, Feb 9, 2020 at 1:59 PM Donal Hunt  wrote:

> I'm the sure the mobility forum and cycling campaign would be happy for a
> mention about the Cork cycling map that was launched last year. The base
> map used OpenStreetMap data before the additional landmarks and highlighted
> routes were added.
>
> https://transportandmobilityforum.com/cork-cycle-map/
>
> Donal
>
> On Sat, 8 Feb 2020 at 14:51, Peter Mooney  wrote:
>
> > Hello everyone,
> >
> > I'm giving a general overview talk about OpenStreetMap in Maynooth
> > University next week, as part of Love Data Week 2020. Details are here
> [1].
> >
> > I only have an hour so I want to show attendees what kinds of
> applications
> > OpenStreetMap is being used for in Ireland and beyond. This will include
> > quick examples of downloading data, using Turbo Overpass online, and a
> very
> > basic map using Leaflet. I'll be showing the work of OSM IE (example the
> > recent Kilkenny work), Townlands, Hieki's visualisations, etc.
> >
> > If you have any other really interesting examples of OSM use which would
> be
> > good for a general audience, please let me know and I'd be delighted to
> > include it.
> >
> > I will make my slides openly available in ODP format afterwards, if they
> > are useful for someone else.
> >
> > With every best wish,
> >
> > Peter
> >
> > [1] https://www.maynoothuniversity.ie/library/events/love-data-week-2020
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
> >
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

[Jonathan Beliën]

Yes, that's the big question mark for the event !
We'll hope to attract people with such knowledge and/or hope to find the 
information online somehow !

That's one of the reason we decided not to edit OpenStreetMap directly during 
the event !

Jonathan Beliën


Mar 11 févr 2020, à 12:18, Jo a écrit :
> I think the hardest part is figuring out what the name stands for if it is a 
> former maire of the city or commune. Especially if we only have an initial 
> for the first name. Sometimes it is possible to find this information on the 
> internet, often it isn't.
> 
> Do we have a way to look into the city's archives?
> 
> Jo
> 
> 
> 
> On Tue, Feb 11, 2020 at 11:07 AM Jonathan Beliën  wrote:
>> __
>>> Given this workflow, I wonder whether we can drop the focus on Wikipedia 
>>> (to save work/time): 1) If there is an existing Wikipedia page, it will 
>>> probably already be linked to the corresponding Wikidata item. 2) If we put 
>>> a Wikidata tag on a street in OSM, I personally see no reason to add a 
>>> Wikipedia tag as well, as the Wikipedia page can be found through the 
>>> Wikidata item (I now not all data consumers will work like that, but I feel 
>>> they should be educated to do so J )
>> 
>> Yes, I thought about adding the `wikipedia` tag if there is a Wikipedia page 
>> but no wikidata "page" but we could indeed add the `wikipedia` tag even if 
>> we have the `wikidata` tag !
>> 
>>> I guess the link between OSM street and Wikidata item for that street will 
>>> be done beforehand (automagically)? In that case, we could really focus on 
>>> the people behind the street names and only fill in the 
>>> name:etymology:wikidata tag in OSM and/or the ‘named after’ statement in 
>>> Wikidata.
>> 
>> Indeed, automagically but (very) carefully !
>> Exact process is not defined yet, I'll consult all of you to find the best 
>> way to do that properly !
>> Addition of the tags in OSM will be done no matter what AFTER the event but 
>> the participant will have access to that information to help them in their 
>> research of course.
>> 
>>> I suppose the participants of the workshop will also have an option to 
>>> indicate 1) is this street named after a person (y/n) 2) which gender does 
>>> the person have (m/f/don’t know)
>> 
>> You suppose correctly !
>> We'll get all those information during the event !
>> But the final process will get the gender from the wikidata "page" (if there 
>> is a wikidata "page" for every person that have a street with their name).
>> 
>> Thanks for the feedback !
>> 
>> Jonathan Beliën
>> 
>> 
>> Mar 11 févr 2020, à 10:56, Santens Seppe a écrit :
>>> Hi Jonathan,

>>> 

>>> Workflow sounds good!

>>> If I may, a few remarks:

>>> · Given this workflow, I wonder whether we can drop the focus on Wikipedia 
>>> (to save work/time): 1) If there is an existing Wikipedia page, it will 
>>> probably already be linked to the corresponding Wikidata item. 2) If we put 
>>> a Wikidata tag on a street in OSM, I personally see no reason to add a 
>>> Wikipedia tag as well, as the Wikipedia page can be found through the 
>>> Wikidata item (I now not all data consumers will work like that, but I feel 
>>> they should be educated to do so J )

>>> · I guess the link between OSM street and Wikidata item for that street 
>>> will be done beforehand (automagically)? In that case, we could really 
>>> focus on the people behind the street names and only fill in the 
>>> name:etymology:wikidata tag in OSM and/or the ‘named after’ statement in 
>>> Wikidata.

>>> · I suppose the participants of the workshop will also have an option to 
>>> indicate 1) is this street named after a person (y/n) 2) which gender does 
>>> the person have (m/f/don’t know)

>>> 

>>> Cheers,

>>> 

>>> Seppe

>>> 

>>> 

>>> *Van:* Jonathan Beliën [mailto:l...@jbelien.be] 
>>> *Verzonden:* dinsdag 11 februari 2020 10:16
>>> *Aan:* talk-be@openstreetmap.org
>>> *Onderwerp:* Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open 
>>> Data

>>> 

>>> Hello everyone,

>>> 

>>> I just find out about this discussion and realize we are currently doing 
>>> the work twice !

>>> 

>>> The initial (and main) goal of the project is indeed to link streets in 
>>> Brussels from OpenStreetMap with the wikidata "page" of the person present 
>>> in the streetname !

>>> 

>>> 

>>> BUT we got in contact with Romain (Wikimedia Belgium) and he told us that 
>>> he is working on creating a wikidata "page" for all the streets in Brussels 
>>> and that his works is almost complete !
>>> So we added that part in our Equal Street Names project !
>>> 

>>> 

>>> For every street in Brussels, we'll add the `wikidata` tag and the 
>>> `name:etymology:wikidata` !

>>> 

>>> My workflow is the following :

>>>  * Make the list of streets in Brussels ; 
>>>* Since almost all the streets have an `associatedStreet` relation in 
>>> Brussels, I'll start with that and add the streets missing ;
>>>* Take the already existing 

Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

[Jo]

I think the hardest part is figuring out what the name stands for if it is
a former maire of the city or commune. Especially if we only have an
initial for the first name. Sometimes it is possible to find this
information on the internet, often it isn't.

Do we have a way to look into the city's archives?

Jo



On Tue, Feb 11, 2020 at 11:07 AM Jonathan Beliën  wrote:

> Given this workflow, I wonder whether we can drop the focus on Wikipedia
> (to save work/time): 1) If there is an existing Wikipedia page, it will
> probably already be linked to the corresponding Wikidata item. 2) If we put
> a Wikidata tag on a street in OSM, I personally see no reason to add a
> Wikipedia tag as well, as the Wikipedia page can be found through the
> Wikidata item (I now not all data consumers will work like that, but I feel
> they should be educated to do so J )
>
>
> Yes, I thought about adding the `wikipedia` tag if there is a Wikipedia
> page but no wikidata "page" but we could indeed add the `wikipedia` tag
> even if we have the `wikidata` tag !
>
> I guess the link between OSM street and Wikidata item for that street will
> be done beforehand (automagically)? In that case, we could really focus on
> the people behind the street names and only fill in the
> name:etymology:wikidata tag in OSM and/or the ‘named after’ statement in
> Wikidata.
>
>
> Indeed, automagically but (very) carefully !
> Exact process is not defined yet, I'll consult all of you to find the best
> way to do that properly !
> Addition of the tags in OSM will be done no matter what AFTER the event
> but the participant will have access to that information to help them in
> their research of course.
>
> I suppose the participants of the workshop will also have an option to
> indicate 1) is this street named after a person (y/n) 2) which gender does
> the person have (m/f/don’t know)
>
>
> You suppose correctly !
> We'll get all those information during the event !
> But the final process will get the gender from the wikidata "page" (if
> there is a wikidata "page" for every person that have a street with their
> name).
>
> Thanks for the feedback !
>
> Jonathan Beliën
>
>
> Mar 11 févr 2020, à 10:56, Santens Seppe a écrit :
>
> Hi Jonathan,
>
>
>
> Workflow sounds good!
>
> If I may, a few remarks:
>
> ·   Given this workflow, I wonder whether we can drop the focus on
> Wikipedia (to save work/time): 1) If there is an existing Wikipedia page,
> it will probably already be linked to the corresponding Wikidata item. 2)
> If we put a Wikidata tag on a street in OSM, I personally see no reason to
> add a Wikipedia tag as well, as the Wikipedia page can be found through the
> Wikidata item (I now not all data consumers will work like that, but I feel
> they should be educated to do so J )
>
> ·   I guess the link between OSM street and Wikidata item for that
> street will be done beforehand (automagically)? In that case, we could
> really focus on the people behind the street names and only fill in the
> name:etymology:wikidata tag in OSM and/or the ‘named after’ statement in
> Wikidata.
>
> ·   I suppose the participants of the workshop will also have an
> option to indicate 1) is this street named after a person (y/n) 2) which
> gender does the person have (m/f/don’t know)
>
>
>
> Cheers,
>
>
>
> Seppe
>
>
>
>
>
> *Van:* Jonathan Beliën [mailto:l...@jbelien.be]
> *Verzonden:* dinsdag 11 februari 2020 10:16
> *Aan:* talk-be@openstreetmap.org
> *Onderwerp:* Re: [OSM-talk-be] 17/02: Towards Equal Street Names with
> Open Data
>
>
>
> Hello everyone,
>
>
>
> I just find out about this discussion and realize we are currently doing
> the work twice !
>
>
>
> The initial (and main) goal of the project is indeed to link streets in
> Brussels from OpenStreetMap with the wikidata "page" of the person present
> in the streetname !
>
>
>
> BUT we got in contact with Romain (Wikimedia Belgium) and he told us that
> he is working on creating a wikidata "page" for all the streets in Brussels
> and that his works is almost complete !
> So we added that part in our Equal Street Names project !
>
>
>
> For every street in Brussels, we'll add the `wikidata` tag and the
> `name:etymology:wikidata` !
>
>
>
> My workflow is the following :
>
>- Make the list of streets in Brussels ;
>- Since almost all the streets have an `associatedStreet` relation in
>   Brussels, I'll start with that and add the streets missing ;
>   - Take the already existing `wikidata` and
>   `name:etymology:wikidata` tags that already exist (on both relations and
>   ways) ;
>   - Romain will provide us the `wikidata` tag for all the streets ;
>   - Next Monday (17/02), we (OSMBE + OKBE + WikimediaBE) organize and
>event to look for all the missing wikidata/wikipedia page related to the
>streets in Brussels ;
>- Workload will be splitted by municipality ;
>   - NOTHING will be added to OSM or Wikipedia/Wikidata during the
>   event ;

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

[Ivo Reano]

>
>
> Da più parti vedo spuntare fuori l'argomento su dove porre il limite di
> una route=hiking rispetto ad una via ferrata o peggio una via alpinistica.
>
> L'argomento non e' solo italiano e non e' venuto fuori ora dopo che il CAI
> ha abbracciato OSM, è un 'argomento vecchiotto dibattuto anche negli
> US anche a causa di incidenti e richieste di soccorso in parte causate da
> problemi di rendering delle varie app.
>
> Ora la cosa sta diventando seria e perché anche da noi fioriscono le
> mappature fantasiose che possono indurre in errore. Fermo restando che chi
> va a fare escursioni non si deve basare solo su quello che vede sullo
> schermo del telefono, e' l'ora di provare a trovare una quadra.
>
Concordo in pieno con la premessa.



> Anche a valle dell'ultimo manuale "Sentieri" di fresca stampa nel quale e'
> stata inserita la classificazione delle guide lombarde che avevo gia'
> riportato qui
> https://wiki.openstreetmap.org/wiki/Proposed_features/cai_scale
> Apporterò qualche modifica e magari faccio la pagina anche in Italiano.
>
Attendo con ansia la versioni italiana perché l'inglese mi è indigesto
(vuol dire che non riesco a contraddire se in inglese!)

Direi che la route=hiking puo' essere tale fino a quando c'è un tratto EEA
> generico che possa essere percorso anche senza imbraco e longe da
> escursionisti esperti con esperienze alpinistiche. Trattasi di quei pezzi
> non particolarmente esposti dove le funi e le catene servono solo da aiuto
> nei tratti più difficili e con rischio di caduta. Con la nuova classifica
> dovrebbero essere passati gradualmente a EEA:F
>
Una definizione chiara dei limiti dell'escursionismo è necessaria. La vedo
difficile, ma non impossibile.


> Oltre la semplice EEA o EEA:F dovrebbero essere vie ferrate e cioè tutte
> quelle che ricadono in EEA:PD, EEA:D, EEA:MD, EEA:E
> Proporrei di usare la relation
> https://wiki.openstreetmap.org/wiki/Proposed_features/via_ferrata
> In questo modo si possono sfruttare i vari pezzi di
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dvia_ferrata
> congiuntamente a pezzi magari di path che unisce, steps, etc.
> Mi sembra un modo più completo di mapparla e dove si può applicare la
> cai_scale
>
+1


>
> Altro argomento sono le climbing route.
> Sembra esserci solo questa tipologia in OSM
> https://wiki.openstreetmap.org/wiki/Climbing#Climbing_Routes
> Si potrebbe pensare di fare anche in questo caso delle relation ma forse
> non è necessario e ci si può uniformare a quel che c'è.
>
Ho trovato già molti siti di arrampicata mappati come nodi e con questi tag.
Troverei difficile mapparle come way dato che lo sviluppo orizzontale è di
qualche metro!

> L'importante è trovare velocemente la quadra in modo da poter cominciare
> a correggere le highway=path di III o IV grado o le highway=path che sono
> invece scale a pioli verticali conficcate nella roccia.
>
+2


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

[OSM-ja] 2/24(月・祝) 兵庫「たかさごでオープンデータソン！」が開催されます

[Jun Nogata]

こんにちは。野方です。
2月24日(月・祝)に兵庫県高砂市で「たかさごでオープンデータソン！」が開催されます。

兵庫県の播磨地域は古いものがいろいろありますが、高砂市にもたくさんあり、
それをまち歩き+OSMマッピングパーティ/Wikipediaタウンで
書いていこうというイベントです。

「たかさごでオープンデータソン！」
日付 ： 2020年2⽉24⽇（⽉・祝）
時間 ： 10:00〜17:30 終了後、懇親会あり
場所 ： ⾼砂商⼯会議所2階⼤会議室
　　　 ⾼砂市⾼砂町北本町1104
参加費：1,000円（学生無料）
※別途懇親会を予定しています。懇親会に参加される方は中学生以上お一人1,500円(実費徴収)します。

イベント案内詳細
https://www.facebook.com/events/546041445992841/

お申し込みはGoogleフォームからお願いします
https://forms.gle/Lqz2LLughGNtv1oA7

定員30名のところ、現在22名の方から申し込みの状況ですので
参加を希望される方は、お早めに申し込みください。

3/7(土)にフォローアップイベントも予定していますので
今回参加が難しい方は、そちらの参加もご検討ください。
詳細については後日公開予定です。

よろしくお願いします。

-- 
野方 純 (NOGATA,Jun) - mail: noga...@gmail.com
 - web: http://www.nofuture.tv/diary/
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-it] Sedi confartigianato

[Andreas Lattmann]

>Mi sembra questo il tag per un >commercialista, è questo il
>confartigianato?

Be, è il servizio principale che offrono: contabilità, paghe, fattura 
elettronica ecc.

Poi in linea molto teorica...

>Pensavo fosse un’associazione di / >rappresentante
>degli interessi degli artigiani?

Dovrebbero rappresentare gli interessi degli artigiani, certamente, anche se ho 
il dubbio che non sia una loro priorità. 

--
樂

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

Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

[Jonathan Beliën]

> Given this workflow, I wonder whether we can drop the focus on Wikipedia (to 
> save work/time): 1) If there is an existing Wikipedia page, it will probably 
> already be linked to the corresponding Wikidata item. 2) If we put a Wikidata 
> tag on a street in OSM, I personally see no reason to add a Wikipedia tag as 
> well, as the Wikipedia page can be found through the Wikidata item (I now not 
> all data consumers will work like that, but I feel they should be educated to 
> do so J )

Yes, I thought about adding the `wikipedia` tag if there is a Wikipedia page 
but no wikidata "page" but we could indeed add the `wikipedia` tag even if we 
have the `wikidata` tag !

> I guess the link between OSM street and Wikidata item for that street will be 
> done beforehand (automagically)? In that case, we could really focus on the 
> people behind the street names and only fill in the name:etymology:wikidata 
> tag in OSM and/or the ‘named after’ statement in Wikidata.

Indeed, automagically but (very) carefully !
Exact process is not defined yet, I'll consult all of you to find the best way 
to do that properly !
Addition of the tags in OSM will be done no matter what AFTER the event but the 
participant will have access to that information to help them in their research 
of course.

> I suppose the participants of the workshop will also have an option to 
> indicate 1) is this street named after a person (y/n) 2) which gender does 
> the person have (m/f/don’t know)

You suppose correctly !
We'll get all those information during the event !
But the final process will get the gender from the wikidata "page" (if there is 
a wikidata "page" for every person that have a street with their name).

Thanks for the feedback !

Jonathan Beliën


Mar 11 févr 2020, à 10:56, Santens Seppe a écrit :
> Hi Jonathan,

> 

> Workflow sounds good!

> If I may, a few remarks:

> · Given this workflow, I wonder whether we can drop the focus on Wikipedia 
> (to save work/time): 1) If there is an existing Wikipedia page, it will 
> probably already be linked to the corresponding Wikidata item. 2) If we put a 
> Wikidata tag on a street in OSM, I personally see no reason to add a 
> Wikipedia tag as well, as the Wikipedia page can be found through the 
> Wikidata item (I now not all data consumers will work like that, but I feel 
> they should be educated to do so J )

> · I guess the link between OSM street and Wikidata item for that street will 
> be done beforehand (automagically)? In that case, we could really focus on 
> the people behind the street names and only fill in the 
> name:etymology:wikidata tag in OSM and/or the ‘named after’ statement in 
> Wikidata.

> · I suppose the participants of the workshop will also have an option to 
> indicate 1) is this street named after a person (y/n) 2) which gender does 
> the person have (m/f/don’t know)

> 

> Cheers,

> 

> Seppe

> 

> 

> *Van:* Jonathan Beliën [mailto:l...@jbelien.be] 
> *Verzonden:* dinsdag 11 februari 2020 10:16
> *Aan:* talk-be@openstreetmap.org
> *Onderwerp:* Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open 
> Data

> 

> Hello everyone,

> 

> I just find out about this discussion and realize we are currently doing the 
> work twice !

> 

> The initial (and main) goal of the project is indeed to link streets in 
> Brussels from OpenStreetMap with the wikidata "page" of the person present in 
> the streetname !

> 


> BUT we got in contact with Romain (Wikimedia Belgium) and he told us that he 
> is working on creating a wikidata "page" for all the streets in Brussels and 
> that his works is almost complete !
>  So we added that part in our Equal Street Names project !

> 

> For every street in Brussels, we'll add the `wikidata` tag and the 
> `name:etymology:wikidata` !

> 

> My workflow is the following :

>  * Make the list of streets in Brussels ; 
>* Since almost all the streets have an `associatedStreet` relation in 
> Brussels, I'll start with that and add the streets missing ;
>* Take the already existing `wikidata` and `name:etymology:wikidata` tags 
> that already exist (on both relations and ways) ;
>* Romain will provide us the `wikidata` tag for all the streets ;
>  * Next Monday (17/02), we (OSMBE + OKBE + WikimediaBE) organize and event to 
> look for all the missing wikidata/wikipedia page related to the streets in 
> Brussels ; 
>* Workload will be splitted by municipality ;
>* NOTHING will be added to OSM or Wikipedia/Wikidata during the event ;
>  * Once we have the `wikidata` and/org `name:etymology:wikidata` tags for 
> each street in Brussels, we'll add those 2 tags to OSM ; 
>* Exact procedure is not defined yet ;
>* Procedure will be documented and we'll ask feedback from the community 
> BEFORE running it ;
> Everything will be documented in a GitHub repository and on OSM wiki (as soon 
> as I have a little time) !

> 

> Long story short, any feedback is more than welcome but let's 

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

[Stéphane Péneau]

Bonjour,

Dupliquer la population sur l'admin-centre me semble une mauvaise idée 
surtout sur les nouvelles communes. En effet, elle a pu être mise à 
jour pour cette ancienne commune seulement et n'a donc pas la même 
valeur que la nouvelle. Je rappelle que beaucoup (la majorité ?) de 
nouvelles communes n'ont pas le même nom que l'ancienne et aussi que 
l'ancienne peut avoir deux relations admin_centre (pour elle-même et 
pour la nouvelle).


Exact, et dans ce cas, je n'ai pas dupliqué la population de la commune 
nouvelle sur l'"admin_centre"


Stf

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

Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

[Santens Seppe]

Hi Jonathan,

Workflow sounds good!
If I may, a few remarks:

·   Given this workflow, I wonder whether we can drop the focus on 
Wikipedia (to save work/time): 1) If there is an existing Wikipedia page, it 
will probably already be linked to the corresponding Wikidata item. 2) If we 
put a Wikidata tag on a street in OSM, I personally see no reason to add a 
Wikipedia tag as well, as the Wikipedia page can be found through the Wikidata 
item (I now not all data consumers will work like that, but I feel they should 
be educated to do so ☺ )

·   I guess the link between OSM street and Wikidata item for that street 
will be done beforehand (automagically)? In that case, we could really focus on 
the people behind the street names and only fill in the name:etymology:wikidata 
tag in OSM and/or the ‘named after’ statement in Wikidata.

·   I suppose the participants of the workshop will also have an option to 
indicate 1) is this street named after a person (y/n) 2) which gender does the 
person have (m/f/don’t know)

Cheers,

Seppe


Van: Jonathan Beliën [mailto:l...@jbelien.be]
Verzonden: dinsdag 11 februari 2020 10:16
Aan: talk-be@openstreetmap.org
Onderwerp: Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

Hello everyone,

I just find out about this discussion and realize we are currently doing the 
work twice !

The initial (and main) goal of the project is indeed to link streets in 
Brussels from OpenStreetMap with the wikidata "page" of the person present in 
the streetname !

BUT we got in contact with Romain (Wikimedia Belgium) and he told us that he is 
working on creating a wikidata "page" for all the streets in Brussels and that 
his works is almost complete !
So we added that part in our Equal Street Names project !

For every street in Brussels, we'll add the `wikidata` tag and the 
`name:etymology:wikidata` !

My workflow is the following :

  *   Make the list of streets in Brussels ;
 *   Since almost all the streets have an `associatedStreet` relation in 
Brussels, I'll start with that and add the streets missing ;
 *   Take the already existing `wikidata` and `name:etymology:wikidata` 
tags that already exist (on both relations and ways) ;
 *   Romain will provide us the `wikidata` tag for all the streets ;
  *   Next Monday (17/02), we (OSMBE + OKBE + WikimediaBE) organize and event 
to look for all the missing wikidata/wikipedia page related to the streets in 
Brussels ;
 *   Workload will be splitted by municipality ;
 *   NOTHING will be added to OSM or Wikipedia/Wikidata during the event ;
  *   Once we have the `wikidata` and/org `name:etymology:wikidata` tags for 
each street in Brussels, we'll add those 2 tags to OSM ;
 *   Exact procedure is not defined yet ;
 *   Procedure will be documented and we'll ask feedback from the community 
BEFORE running it ;
Everything will be documented in a GitHub repository and on OSM wiki (as soon 
as I have a little time) !

Long story short, any feedback is more than welcome but let's not step upon 
each other and try to coordinate our effort !
I've been hired by Open Knowledge Belgium to work on that project.

Have a nice day !

Jonathan Beliën


Mar 11 févr 2020, à 09:06, Jo a écrit :
OK, in that case, we'll have to go back to the original source, Urbis if we 
want to add coordinates for the streets to Wikidata.

I always thought that if I'm the one who adds features to OSM myself, or if I'm 
the one who places them at their correct spot, using aerial imagery that the 
data was mine and I could contribute it to Wikidata, if that pleases me. But 
maybe I shouldn't link back to OSM in that case in the reference url.

Seppe, Joost and Jonathan's project is about linking through 
name:etymology:wikidata to persons, and add those persons to Wikidata if they 
don't exist there yet. No addition of geodata involved in that  case.

I know that Romaine has the wish for several years now, to add the streets of 
Brussels themselves to Wikidata.

 Cheers,

Jo

On Tue, Feb 11, 2020 at 7:56 AM Marc Gemis 
mailto:marc.ge...@gmail.com>> wrote:
> About the geocoding. If I look at the street in my JOSM, then create a node 
> somewhere in the center of it and then add the coordinates of that node to 
> Wikidata, did I violate any rights? If it does, we could use Urbis data to 
> source coordinates for the whereabouts of the street. I'm not using any nodes 
> of the street itself. I do try to link back to openstreetmap (one of the ways 
> or associatedStreet relation) in the reference url field.
>

IMHO, that is a derivative database. You look at OSM data, apply some
algorithm and create new data.
AFAIK, the project that Seppe, Joost and Jonathan have will not add
such data, but if you want to do it, you might contact the LWG to be
sure it's OK. I doubt it is.

regards

m.
___
Talk-be mailing list
Talk-be@openstreetmap.org

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

[Jérôme Seigneuret]

>
>
>
> à chaud, j'aurais créé traffic_sign=surveillance
> ___
>
Pour moi c'est pas en lien avec le traffic

A chaud ;-)
tourism=information
information=bord
bord_type=surveillance

Cordialement,
Jérôme Seigneuret
___
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]

Pas à ma connaissance
C'est un panneau informatif au même titre que ceux pour signaler le 0
phyto, ville fleuri ...

Si je ne me trompe pas c'est juste un élément qui répond à une
recommandation de la CNIL en terme de signalement au usager.



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

> Bonjour,
>
> Les panneaux indiquant les zones vidéosurveillées ne semblent pas
> standardisés.
>
> Existe-t-il néammoins un tag pour tagger ces panneaux correctement ?
>
> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Sedi confartigianato

[Martin Koppenhoefer]

Mi sembra questo il tag per un commercialista, è questo il confartigianato? 
Pensavo fosse un’associazione di / rappresentante degli interessi degli 
artigiani?

Ciao Martin 

sent from a phone

> Il giorno 11 feb 2020, alle ore 10:08, Andreas Lattmann 
>  ha scritto:
> 
> Io l'ho iseriti così:
> 
> building=office
> office=accountant
> opening_hours=Mo-Fr 08:30-12:30, 14:00-18:00
> 
> Ora che guardo ma non ricordo di averlo inserito c'è anche

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

Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

[Jonathan Beliën]

Hello everyone,

I just find out about this discussion and realize we are currently doing the 
work twice !

The initial (and main) goal of the project is indeed to link streets in 
Brussels from OpenStreetMap with the wikidata "page" of the person present in 
the streetname !

BUT we got in contact with Romain (Wikimedia Belgium) and he told us that he is 
working on creating a wikidata "page" for all the streets in Brussels and that 
his works is almost complete !
So we added that part in our Equal Street Names project !

For every street in Brussels, we'll add the `wikidata` tag and the 
`name:etymology:wikidata` !

My workflow is the following :
 * Make the list of streets in Brussels ;
   * Since almost all the streets have an `associatedStreet` relation in 
Brussels, I'll start with that and add the streets missing ;
   * Take the already existing `wikidata` and `name:etymology:wikidata` tags 
that already exist (on both relations and ways) ;
   * Romain will provide us the `wikidata` tag for all the streets ;
 * Next Monday (17/02), we (OSMBE + OKBE + WikimediaBE) organize and event to 
look for all the missing wikidata/wikipedia page related to the streets in 
Brussels ;
   * Workload will be splitted by municipality ;
   * NOTHING will be added to OSM or Wikipedia/Wikidata during the event ;
 * Once we have the `wikidata` and/org `name:etymology:wikidata` tags for each 
street in Brussels, we'll add those 2 tags to OSM ;
   * Exact procedure is not defined yet ;
   * Procedure will be documented and we'll ask feedback from the community 
BEFORE running it ;
Everything will be documented in a GitHub repository and on OSM wiki (as soon 
as I have a little time) !

Long story short, any feedback is more than welcome but let's not step upon 
each other and try to coordinate our effort !
I've been hired by Open Knowledge Belgium to work on that project.

Have a nice day !

Jonathan Beliën


Mar 11 févr 2020, à 09:06, Jo a écrit :
> OK, in that case, we'll have to go back to the original source, Urbis if we 
> want to add coordinates for the streets to Wikidata.
> 
> I always thought that if I'm the one who adds features to OSM myself, or if 
> I'm the one who places them at their correct spot, using aerial imagery that 
> the data was mine and I could contribute it to Wikidata, if that pleases me. 
> But maybe I shouldn't link back to OSM in that case in the reference url.
> 
> Seppe, Joost and Jonathan's project is about linking through 
> name:etymology:wikidata to persons, and add those persons to Wikidata if they 
> don't exist there yet. No addition of geodata involved in that case.
> 
> I know that Romaine has the wish for several years now, to add the streets of 
> Brussels themselves to Wikidata.
> 
>  Cheers,
> 
> Jo
> 
> On Tue, Feb 11, 2020 at 7:56 AM Marc Gemis  wrote:
>> > About the geocoding. If I look at the street in my JOSM, then create a 
>> > node somewhere in the center of it and then add the coordinates of that 
>> > node to Wikidata, did I violate any rights? If it does, we could use Urbis 
>> > data to source coordinates for the whereabouts of the street. I'm not 
>> > using any nodes of the street itself. I do try to link back to 
>> > openstreetmap (one of the ways or associatedStreet relation) in the 
>> > reference url field.
>>  >
>> 
>>  IMHO, that is a derivative database. You look at OSM data, apply some
>>  algorithm and create new data.
>>  AFAIK, the project that Seppe, Joost and Jonathan have will not add
>>  such data, but if you want to do it, you might contact the LWG to be
>>  sure it's OK. I doubt it is.
>> 
>>  regards
>> 
>>  m.
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Shohreh]

Bonjour,

Les panneaux indiquant les zones vidéosurveillées ne semblent pas
standardisés.

Existe-t-il néammoins un tag pour tagger ces panneaux correctement ?

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

Re: [Talk-it] Sedi confartigianato

[Andreas Lattmann]

Io l'ho iseriti così:

building=office
office=accountant
opening_hours=Mo-Fr 08:30-12:30, 14:00-18:00

Ora che guardo ma non ricordo di averlo inserito c'è anche 

amenity=accountant

Probabilmente ridondante.
樂


Il 11 febbraio 2020 09:39:15 CET, Matteo Zaffonato  ha 
scritto:
>Ciao a tutti,
>risolvendo una nota di una gelateria ho controllato la loro pagina
>facebook
>in cerca di dettagli e mi sono inbattuto in questo sito [1] della
>Confartigianato di San Donà di Piave. Mi chiedevo che tag usare per
>inserire le sedi di cui trovo il numero civico, in Veneto ho trovato
>tre
>esempi tramite Overpass Turbo ed uno solo aveva un office=comapny (gli
>altri avevano un building=yes).
>
>Avete qualche suggerimento?
>
>Ciao, grazie
>Matteo
>
>[1] https://www.artigianisandona.it/contatti/

--
樂

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

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

[Jérôme Seigneuret]

*je comprend pas ce que tu veux dire avec cette totologie.une limite
urbaine est un panneau EB20 et vice-versa.a-t-on besoin de dire que si on
suit le chemin inverse d'une entréec'est une sortie ? cela me semble lourd
pour un gain qui m’échappe.  *

Je suis d'accord sur ce sujet. Un FR:EB20 c'est égal à la valeur de sortie
du city_limit

Ducoup c'est soit l'un soit l'autre dans le cas du point sur le réseau
traffic_sign=city_limit
ou
traffic_sign=FR:EB20 pour la sortie d'une voie en sens unique
traffic_sign=FR:EB10  pour les autre cas on peut considéré que c'est le cas
implicite

Sinon c'est hors topologie avec placement au réel du panneau ce qui permet
d'identifier la présence ou absence de matériel sur le terrain.
Graphiquement. L'analyse de vitesse on s'en fou un peu puisse que le
maxspeed doit être saisie sur la voie et que la source d'information est
matérialisé.

traffic_sign=FR:EB10 et traffic_sign=FR:EB20 Prennent tous leur sens et
c'est les problème que l'on a toujours entre Montpellier Lattes et
Saint-Jean de Védas où on a de réel problème pour les vitesses
portion à 50 ou à 80 voir 90 avant l'entrée sur le rond point.

sortie 1  90
https://www.mapillary.com/map/im/ixB69C61ZJJIDtY3KLZzrw
entrée 1 50
https://www.mapillary.com/map/im/Zo3aje8wMAYuV5kjF0QLdA

sortie 2 90
https://www.mapillary.com/map/im/wst74HSo9hjkXTabdGlKxQ
entrée 2 50
https://www.mapillary.com/map/im/OoJ7Mk2eXmhsA0fy6LUD-w

sortie 3 80
https://www.mapillary.com/map/im/KSwwyWu3Pl53VKzXhj4CdQ
entrée 3 50
ici suivant d'où je viens j'ai un problème clair de vitesse

J'ai pas de photo mais au bout de la sortie 3 le l'autre coté du rond point
on a un panneau d'entrée mais pas de sortie ce qui génère un problème de
topologie. Et en base on fait quoi? et les outils traite le problème
comment?
C'est un peu comme le trou ou le chevauchement sur des limites de
frontières dont les pays sont en désaccord.

C'est pour cela que je préfère les implantations réelles puis fournir sur
le tronçon l'information de vitesse correspondantes (ou une erreur à
corriger).

Je vais pas reprendre le cours sur le traitement des vitesses du code de la
route mais on pourrait envisager de détailler ce point sur le wiki vu la
problématique.


*Si l’autorité détentrice du pouvoir de police souhaite abaisser la
vitesse, il doit en principe rappeler cette limite après chaque
intersection. Mais il dispose également de différents outils qui permettent
de ne pas rappeler la vitesse à chaque intersection (cas des panneaux de
zones)  *

Le problème c'est le suivi du développement urbain qui n'est pas forcément
réanalysé en terme de signalisation
Pour moi ces panneaux sont dans tous les cas indispensable à leur
emplacement pour bien interpréter la réalité terrain. Si on met l'info de
vitesse sur le tronçon c'est pour éviter ces cas d'interprétation par les
outils vu que c'est pas performant et que ça pause aussi des problèmes
problème de responsabilité. C'est pour cela que l'on a autant de problème à
trouver des sources fiable sur le sujet alors que les DDTM on des infos sur
les implantations de leurs panneaux. Pour les communes j'en parle pas car
vu les problèmes il est clair que l'on ne retrouvera des infos que dans 30%
des cas.

Ne pas oublier qu'un panneau 30 sous un panneau de ville transpose
l'ensemble de l'agglomération à 30km/h sauf signalisation au sol ou
vertical signalant le contraire dans l'agglomération (oui la ville peut
être limité à 30km/h sauf axes majeurs qui peuvent être élevé à une vitesse
de 70km/h
https://www.ornikar.com/code/cours/panneaux/interdiction/limitation-vitesse#les-panneaux-en-agglomeration-1


J'ai corrigé la ville de Beauvoisin  en ce sens.
https://www.openstreetmap.org/node/7121675138  Nœud simple sur le réseau
(pour le moment)
Le problème reste les chemins sur lesquels il manque les panneaux d'entrée
et sortie et qui retombent sur la départementale hors agglomération... Les
chemin sont carrossés...

Bonne journée

Le mar. 11 févr. 2020 à 00:18, marc marc  a
écrit :

> Bonsoir,
>
> Le 10.02.20 à 21:59, onesim...@free.fr a écrit :
> > Je pense qu’on va partir sur des points à proximité de la route, à
> > l’emplacement exact du panneau.
>
> je me demande s'il y un logiciel de routage qui l'utilisera
>
> > Il n’est pas possible de mettre 2 fois la même clé par ex. :
>
> si : clef=valeur1;valeur2 (exemple avec la clef cuisine
>
> > donc une alternative et une meilleure manière de le noter est la
> suivante :
> > - traffic_sign=city_limit,FR:EB20.
>
> je comprend pas ce que tu veux dire avec cette totologie.
> une limite urbaine est un panneau EB20 et vice-versa.
> a-t-on besoin de dire que si on suit le chemin inverse d'une entrée
> c'est une sortie ? cela me semble lourd pour un gain qui m’échappe.
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret

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

[Andreas Lattmann]

Concordo. 

Il 10 febbraio 2020 21:21:08 CET, Alfredo Gattai  ha 
scritto:
>Ciao lista,
>
>scusate in anticipo per la lungaggine ma e' necessaria.
>
>Da piu' parti vedo spuntare fuori l'argomento su dove porre il limite
>di
>una route=hiking rispetto ad una via ferrrata o peggio una via
>alpinistica.
>
>L'argomento non e' solo italiano e non e' venuto fuori ora dopo che il
>CAI
>ha abbracciato OSM, e' un'argomento vecchiotto dibattuto anche negli
>US anche a causa di incidenti e richieste di soccorso in parte causate
>da
>problemi di rendering delle varie app.
>
>Ora la cosa sta diventanto seria e perche' anche da noi fioriscono le
>mappature fantasiose che possono indurre in errore. Fermo restando che
>chi
>va a fare escursioni non si deve basare solo su quello che vede sullo
>schermo del telefono, e' l'ora di provare a trovare una quadra.
>
>Anche a valle dell'ultimo manuale "Sentieri" di fresca stampa nel quale
>e'
>stata inserita la classificazione delle guide lombarde che avevo gia'
>riportato qui
>https://wiki.openstreetmap.org/wiki/Proposed_features/cai_scale
>Apportero' qualche modifica e magari faccio la pagina anche in
>Italiano.
>
>Direi che la route=hiking puo' essere tale fino a quando c'e' un tratto
>EEA
>generico che possa essere percorso anche senza imbraco e longe da
>escursionisti esperti con esperienze alpinistiche. Trattasi di quei
>pezzi
>non particolarmente esposti dove le funi e le catene servono solo da
>aiuto
>nei tratti piu' difficili e con rischio di caduta. Con la nuova
>classifica
>dovrebbero essere passati gradualmente a EEA:F
>
>Oltre la semplice EEA o EEA:F dovrebbero essere vie ferrate e cioe'
>tutte
>quelle che ricadono in EEA:PD, EEA:D, EEA:MD, EEA:E
>Proporrei di usare la relation
>https://wiki.openstreetmap.org/wiki/Proposed_features/via_ferrata
>In questo modo si possono sfruttare i vari pezzi di
>https://wiki.openstreetmap.org/wiki/Tag:highway%3Dvia_ferrata
>congiuntamente a pezzi magari di path che unisce, steps, etc.
>Mi sembra un modo piu' completo di mapparla e dove si puo' applicare la
>cai_scale
>
>Altro argomento sono le climbing route.
>Sembra esserci solo questa tipologia in OSM
>https://wiki.openstreetmap.org/wiki/Climbing#Climbing_Routes
>Si potrebbe pensare di fare anche in questo caso delle relation ma
>forse
>non e' necessario e ci si puo' uniformare a quel che c'e'.
>L'importante e' trovare velocemente la quadra in modo da poter
>cominciare a
>correggere le highway=path di III o IV grado o le highway=path che sono
>invece scale a pioli verticali conficcate nella roccia.
>
>Alfredo

--
樂

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

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

[Rpnpif via Talk-fr]

Le 10/02/2020 à 18:00, leni a écrit :


Le 10/02/2020 à 12:29, Stéphane Péneau a écrit :

Si je récapitule :

- Vincent lance l'outil aidant la maj de la population sur les 
relations des communes.


- Je soulève l'idée de supprimer le tag "population" des noeuds car 
ce n'est pas cohérent.


- Christian indique qu'il l'utilise

- Discussions sur les différents cas qui se présentent. Avec 
plusieurs propositions de supprimer "population" des noeuds.


- J'indique que si c'est utilisé par le rendu FR, ça bloque un peu ce 
processus.



Dans ma tête, j'en suis resté à l'idée qu'il fallait le conserver 
pour l'instant, et sur les maj que j'ai effectuées, j'ai copié la 
valeur de "population" sur le noeud "admin_centre".


j'ai fait pareil après avoir lu le message de Christian 


Bonjour,

Dupliquer la population sur l'admin-centre me semble une mauvaise idée 
surtout sur les nouvelles communes. En effet, elle a pu être mise à jour 
pour cette ancienne commune seulement et n'a donc pas la même valeur que 
la nouvelle. Je rappelle que beaucoup (la majorité ?) de nouvelles 
communes n'ont pas le même nom que l'ancienne et aussi que l'ancienne 
peut avoir deux relations admin_centre (pour elle-même et pour la nouvelle).


D'ailleurs, le traitement des nouvelles communes et particulièrement 
leur rendu est un problème à part entière qui est très mal traité par le 
rendu osm.org, contrairement à Géoportail (de l'IGN) qui fait bien 
apparaître son nom.


Je vais lancer un autre fil de discussion sur ce problème des nouvelles 
communes.


Rpnpif


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

[Talk-it] Sedi confartigianato

[Matteo Zaffonato]

Ciao a tutti,
risolvendo una nota di una gelateria ho controllato la loro pagina facebook
in cerca di dettagli e mi sono inbattuto in questo sito [1] della
Confartigianato di San Donà di Piave. Mi chiedevo che tag usare per
inserire le sedi di cui trovo il numero civico, in Veneto ho trovato tre
esempi tramite Overpass Turbo ed uno solo aveva un office=comapny (gli
altri avevano un building=yes).

Avete qualche suggerimento?

Ciao, grazie
Matteo

[1] https://www.artigianisandona.it/contatti/
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

[Jo]

OK, in that case, we'll have to go back to the original source, Urbis if we
want to add coordinates for the streets to Wikidata.

I always thought that if I'm the one who adds features to OSM myself, or if
I'm the one who places them at their correct spot, using aerial imagery
that the data was mine and I could contribute it to Wikidata, if that
pleases me. But maybe I shouldn't link back to OSM in that case in the
reference url.

Seppe, Joost and Jonathan's project is about linking through
name:etymology:wikidata to persons, and add those persons to Wikidata if
they don't exist there yet. No addition of geodata involved in that  case.

I know that Romaine has the wish for several years now, to add the streets
of Brussels themselves to Wikidata.

 Cheers,

Jo

On Tue, Feb 11, 2020 at 7:56 AM Marc Gemis  wrote:

> > About the geocoding. If I look at the street in my JOSM, then create a
> node somewhere in the center of it and then add the coordinates of that
> node to Wikidata, did I violate any rights? If it does, we could use Urbis
> data to source coordinates for the whereabouts of the street. I'm not using
> any nodes of the street itself. I do try to link back to openstreetmap (one
> of the ways or associatedStreet relation) in the reference url field.
> >
>
> IMHO, that is a derivative database. You look at OSM data, apply some
> algorithm and create new data.
> AFAIK, the project that Seppe, Joost and Jonathan have will not add
> such data, but if you want to do it, you might contact the LWG to be
> sure it's OK. I doubt it is.
>
> regards
>
> m.
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be