Re: [OSM-talk] mapping outside Europe

[Mateusz Konieczny]

7 Jan 2020, 20:53 by ma...@anche.no:

> On 07/01/2020 14:38, Marc Gemis wrote:
>
>> Since OSM is a do-ocracy, do not complain, but write the wiki page you
>> want to see
>>
>
> that's fine, and I've been doing that for Panama, and for Morocco, but I do 
> not like mapping without having reached a consensus.
>
> for that, we need other mappers to contribute to the discussion, and I never 
> managed to get any far on this in the wiki (actually, not even in the 
> changeset comments).
>
Is the community using some FB group, Telegram channel or Discord or some even 
more unusual
discussion location?

> so you say: just revolutionize the overview for the highway tag, without 
> first reaching a consensus?
>
Obviously no.

> replace the Eurocentric pictures with Panama and Morocco pics?
> an edit like this will be reverted after 15 minutes!
>
Is a new photo differing in content (confusing for Europeans in the similar way 
as original
was confusing for people from Panama)? Then both should be present, one in the 
infobox,
one in the article text.

Is the new photo usable as illustration in both cases and differs by decoration 
(people are wearing different clothes etc)? Can you link an edit where it was 
reverted
(except cases where new non-european image was of a lower quality)?

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

[OSM-talk-fr] la voie verte fantôme

[Arnaud Champollion]

Bonjour,

Dans le bassin dignois nous avons des contributions "fantômes".

Parmi celles-ci : la "voie verte utile", exemple :

https://www.openstreetmap.org/way/634099209#map=18/44.04107/6.04247

C'est taggué comme une piste cyclable existante, nommé "voie verte 
utile", mais :


- ça ne correspond à rien sur le terrain

- ça ne correspond à aucun chantier en cours

- ça ne correspond à aucun projet acté

Ça correspond plus ou moins à une des idées qui vont et viennent dans le 
cadre du débat "train vs voie verte" qui a lieu dans les Alpes de Haute 
Provence, mais cela ne va pas plus loin.


En attendant sur tous les rendus ça fait apparaître des chemins, parfois 
qui font doublon avec un chemin existant, parfois qui passent sur une 
route, et parfois qui traversent des champs ou forts alors qu'il n'y a 
rien sur le terrain.


Le contributeur à l'origine de ces ajouts a été sollicité plusieurs fois 
via les commentaires de changeset sur cette question, mais il n'y a 
jamais de réponse.


Avez-vous déjà été confronté à ce genre de choses ? Est-il envisageable 
de supprimer purement et simplement ces chemins ?





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

Re: [OSM-talk-fr] Ces raccourcis JOSM que l'on découvre "trop tard"

[Arnaud Champollion]

Le 06/01/2020 à 22:41, Christian Quest a écrit :

Bah... on corrige ;)


C'est bon je pense avoir réussi, en utilisant la fonction "aligner les 
points", comme il se trouvait par chance que les deux landuse étaient 
mitoyens par une section droite :


https://www.openstreetmap.org/way/761238833#map=19/44.08270/6.21565


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

[OSM-talk] Why we have only four layers on the osm site was: names of international objects

[Mateusz Konieczny]

8 Jan 2020, 07:14 by m...@ayeltd.biz:

>  it puzzles me why 15 years  into the project we only have 4 layers on 
> our main site.
>
Noone except them is willing to sponsor hosting a rendering.

>
> Mike
>
>
>
>
>
> Note that we do have some great projects in the wealthier  economies such 
> as > https://openstreetmap.se/>  > https://openstreetmap.jp>  > 
> https://www.openstreetmap.de/>   ... Why  aren't these integrated in some 
> way into our main site !?
>
>
They are unwilling to add them to the main site, due to hosting cost issues.
(or may be unaware that it is possible, but I am betting that it is a funding 
issue)

See https://wiki.openstreetmap.org/wiki/Featured_tile_layers
https://wiki.openstreetmap.org/wiki/Featured_tile_layers/Guidelines_for_new_tile_layers

"hard criteria" can be shortened to "you must sponsor a hosting of tile layer 
that you propose to add"
(+"The proposed tile layer must not use any non-free data.")
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Diversity-talk] Diversity 2020 Article

[Clifford Snow]

Personally I don't think OSM having a CoC would reach to social media with
the possible exception of a person writing as an official of OSM, such as a
board member or working group. The goal of a CoC is to create a
welcoming inclusive community within OSM. Social media can be a toxic
environment that we as a community can't control. Yes, I'd like to see
Facebook, Reddit, Twitter, etc. clean up their act, but we have little or
no influence to do so. I live by one of Stephen Covey principles that we
should focus on what we have influence over not on our circle of concern.
What we do have is influence over is how inclusive and welcoming our
community treats other. We may be concerned about what's on Twitter,
Facebook, etc. but have no influence.

Best,
Clifford

On Tue, Jan 7, 2020 at 8:17 PM Marc Gemis  wrote:

> Would a Code of Conduct also apply to social media that are not
> controlled by OSM/OSMF?
> E.g. Twitter is currently used by a certain part of the community to
> ridicule and criticize people writing on the mailing lists.
>
> regards
>
> m.
>
> On Wed, Jan 8, 2020 at 1:16 AM Clifford Snow 
> wrote:
> >
> >
> https://www.techrepublic.com/article/diversity-why-open-source-needs-to-work-on-it-in-2020/
> is an interesting read. The article talks about open source, but I don't
> see any significant difference between an open data project or an open
> source software project.
> >
> > What I took away from the article is
> >
> > We need to be more inclusive
> > Men (especially over 45) don't see diversity as an issue
> > Younger community members see things getting better
> > We need a clear and enforced Code of Conduct to create a welcoming
> community
> > Quotas are not the answer
> >
> > Just for the record, I'm a while male over (way over) 45.
> >
> > Happy New Year,
> > Clifford
> >
> > --
> > @osm_washington
> > www.snowandsnow.us
> > OpenStreetMap: Maps with a human touch
> > ___
> > Diversity-talk mailing list
> > Code of Conduct:
> https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
> > Contact the mods (private): diversity-talk-ow...@openstreetmap.org
>


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
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] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[Jo]

You forgot OpenStreetMap.fr and osm.be

On Wed, Jan 8, 2020, 07:18 Michael Collinson  wrote:

> On 2020-01-07 18:27, Mateusz Konieczny wrote:
>
> 6 Jan 2020, 16:35 by dieterdre...@gmail.com:
>
> On 6. Jan 2020, at 07:29, Maarten Deen  
> wrote:
>
> Baltic Sea to be the "Baltic Sea" or for South America to be "South
> America" - this is an example of English imperialism.
>
> This "imperialism" idea of yours is just your idea. It is not something
> that is widely felt.
>
> regarding imperialism, I think it’s hard to reject the reasoning that
> English is in widespread use because of imperialism.
>
> Yes, but using it for a pragmatic reasons
> for an international communication is
> usually not imperialism.
>
> I can try to communicate with group of  people
> from different countries in Polish,
> Latin, Sindarin or Esperanto.
>
> But except rare cases using English is likely
> to result in more efficient communication.
>
> Totally agree with Mateusz. English is the current trading language. It
> has been Farsi and other languages in the past. It will probably Mandarin
> Chinese/simplified hanji in the future. But right now it is English.
>
> I think the whole debate misses the point. The OSM database is
> language-agnostic right now. The https://www.openstreetmap.org slippy map
> was intended to A map show-casing the database. But it has turned into THE
> map.
>
> A potential solution is to offer centralised support for other lingual
> (and culture, which is not always the same thing) maps. That of course is a
> much easier thing to say rather than do as it requires time and money
> resource, but it puzzles me why 15 years into the project we only have 4
> layers on our main site.
>
>
> Mike
>
>
> Note that we do have some great projects in the wealthier economies such
> as https://openstreetmap.se/ https://openstreetmap.jp
> https://www.openstreetmap.de/  ... Why aren't these integrated in some
> way into our main site !?
> ___
> 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] mapping outside Europe

[Maarten Deen]

On 2020-01-07 20:53, Mario Frasca wrote:

On 07/01/2020 14:38, Marc Gemis wrote:

Since OSM is a do-ocracy, do not complain, but write the wiki page you
want to see


that's fine, and I've been doing that for Panama, and for Morocco, but
I do not like mapping without having reached a consensus.

for that, we need other mappers to contribute to the discussion, and I
never managed to get any far on this in the wiki (actually, not even
in the changeset comments).  in particular Panama, none of the local
mappers seem to use the wiki,


If they don't use the wiki, then who complains about missing local 
information in the wiki?


Regards,
Maarten

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

Re: [talk-cz] [osm_sk] WeeklyOSM CZ 492

[Robert C.]

Věděli jste …
… že můžete mapovat vybavení hřišť jako nezávislé objekty v OSM s pomocí
tagu Key:playground?

-> vie niekto aj o mape kde by sa playground renderoval? (myslim samotne
prvky)

ut 7. 1. 2020 o 10:40 Tom Ka  napísal(a):

> Ahoj, je dostupné vydání 492 týdeníku WeeklyOSM:
>
> https://weeklyosm.eu/cz/archives/12676
>
> * CZ a SK překlad rad pro komentáře.
> * Evoluce OSM v Irsku.
> * Manuál Overpass API.
> * Proč nový Switch2OSM?
> * Den otevřených dat.
> * Novinky iD v2.17.0.
> * Nej mapy za 2019.
> * Jak na obrázky týdne?
> * Útoky na GPS v Číně.
> * Návrh změn v Apple Maps.
> * 35let klimatu Arktidy.
> * GPS pro cyklisty s OSM.
>
> Pěkné počtení ...
>
> --
> Túto správu ste prijali, pretože ste prihlásení na odber správ skupiny
> „Openstreetmap Slovakia“ služby Skupiny Google.
>
> Ak chcete zrušiť odber tejto skupiny a prestať od nej prijímať e-maily,
> pošlite e-mail na adresu osm_sk+unsubscr...@googlegroups.com.
> Ak chcete zobraziť túto diskusiu na webe, prejdite na adresu
> https://groups.google.com/d/msgid/osm_sk/CAHqEKC1EjeNxPzGouHUQ6Mo418j-ELOumUbHvMnE%2BJFrMKV6Hw%40mail.gmail.com
> .
>


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

Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[Michael Collinson]

On 2020-01-07 18:27, Mateusz Konieczny wrote:

6 Jan 2020, 16:35 by dieterdre...@gmail.com:

On 6. Jan 2020, at 07:29, Maarten Deen  wrote:

Baltic Sea to be the "Baltic Sea" or for South America to
be "South
America" - this is an example of English imperialism.

This "imperialism" idea of yours is just your idea. It is not
something that is widely felt.

regarding imperialism, I think it’s hard to reject the reasoning
that English is in widespread use because of imperialism.

Yes, but using it for a pragmatic reasons
for an international communication is
usually not imperialism.

I can try to communicate with group of  people
from different countries in Polish,
Latin, Sindarin or Esperanto.

But except rare cases using English is likely
to result in more efficient communication.


Totally agree with Mateusz. English is the current trading language. It 
has been Farsi and other languages in the past. It will probably 
Mandarin Chinese/simplified hanji in the future. But right now it is 
English.


I think the whole debate misses the point. The OSM database is 
language-agnostic right now. The https://www.openstreetmap.org slippy 
map was intended to A map show-casing the database. But it has turned 
into THE map.


A potential solution is to offer centralised support for other lingual 
(and culture, which is not always the same thing) maps. That of course 
is a much easier thing to say rather than do as it requires time and 
money resource, but it puzzles me why 15 years into the project we only 
have 4 layers on our main site.



Mike


Note that we do have some great projects in the wealthier economies such 
as https://openstreetmap.se/ https://openstreetmap.jp 
https://www.openstreetmap.de/  ... Why aren't these integrated in some 
way into our main site !?


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

Re: [talk-au] Fire Station Operators

[Graeme Fitzpatrick]

No, just confirming details was all I was thinking about!

Thanks

Graeme


On Wed, 8 Jan 2020 at 14:57, Andrew Harvey  wrote:

> It's normally considered okay to check a business website as a reference
> and picking up their contact details, but to err on the side of caution
> taking a whole database from fire.nsw.gov.au and mass importing is not
> advised.
>
> So I'd suggest not just copying everything from that website. For the RFS
> operated fire stations normally the name will indicate this, or a quick
> look at google search results may also indicate, sometimes it's visible on
> Mapillary based on the signage.
>
> On Wed, 8 Jan 2020 at 15:39, Graeme Fitzpatrick 
> wrote:
>
>> Just a thought?
>>
>> Are we allowed to use  https://www.fire.nsw.gov.au/page.php?id=467 or
>> not?
>>
>> I've thinking we would still need permission & waiver?
>>
>> Big question, I guess, is - are we commercial or not?
>>
>> Thanks
>>
>> Graeme
>>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Fire Station Operators

[Andrew Harvey]

It's normally considered okay to check a business website as a reference
and picking up their contact details, but to err on the side of caution
taking a whole database from fire.nsw.gov.au and mass importing is not
advised.

So I'd suggest not just copying everything from that website. For the RFS
operated fire stations normally the name will indicate this, or a quick
look at google search results may also indicate, sometimes it's visible on
Mapillary based on the signage.

On Wed, 8 Jan 2020 at 15:39, Graeme Fitzpatrick 
wrote:

> Just a thought?
>
> Are we allowed to use  https://www.fire.nsw.gov.au/page.php?id=467 or not?
>
> I've thinking we would still need permission & waiver?
>
> Big question, I guess, is - are we commercial or not?
>
> Thanks
>
> Graeme
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Over 55’s Lifestyle Village = retirement_home ?

[cleary]

Sorry I'm a little slow to respond to this question. I have been thinking about 
it. particularly in the context of a similar property that I mapped a few years 
ago.  I had previously tagged it as a social_facility but that is not correct.

Upon reflection, I have changed the tags for 
https://www.openstreetmap.org/way/313767655  
This is a fenced and gated community for residents aged 50+.  I think the area 
is zoned similar to a caravan park so that residents lease the land but provide 
their own demountable buildings and do not necessarily have secure tenure in 
the location.

I have now tagged it as : 

access=private
addr:street=Majestic Drive
addr:suburb=Stanhope Gardens
barrier=fence
landuse=residential
min_age=50
name=Gateway Lifestyle Stanhope Gardens
old_name=Parklea Garden Village
operator=Gateway Lifestyle
place=neighbourhood
residential=leasehold_only
source:name=survey
website=https://www.gatewaylifestyle.com.au/community/stanhope-gardens

Any feedback or comments welcome




On Mon, 6 Jan 2020, at 11:34 AM, Sebastian Spiess wrote:
> Hi all,
> 
> is a Over 55’s Lifestyle Village (like this one
> https://www.middlerockhomevillage.com.au) a amenity=retirement_home?
> 
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dretirement_home
> 
> I'm not clear if the Lifestyle Village is only a fancy marketing name or
> not. I've seen such villages and some are past caravan parks that have
> been re-purposed with the over 55's as clientel.
> 
> How would you tag this?
> 
> 
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>

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

Re: [talk-au] Fire Station Operators

[Graeme Fitzpatrick]

Just a thought?

Are we allowed to use  https://www.fire.nsw.gov.au/page.php?id=467 or not?

I've thinking we would still need permission & waiver?

Big question, I guess, is - are we commercial or not?

Thanks

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

Re: [Talk-us] Railway improvements; stations vs. halts

[Joseph Eisenberg]

According to the wiki page, railway=halt is mainly used for "A small
station, may not have a platform, trains may only stop on request."
The presence of points/switches is only significant in Germany.

I would recommend reverting to railway=station for any which have
platforms and are regularly scheduled places for the train to stop.

-Joseph Eisenberg

On 1/8/20, Clay Smalley  wrote:
> Hi all,
>
> Over the last few months, I've been doing some systematic improvements to
> the passenger railway network across North America. Much of this has been
> filling out public_transport=stop_area relations for every railway station,
> including stop positions and platforms, as well as verifying the geometry
> of the underlying railways and classifying them (usage=*, service=*). My
> goal here is to prepare the map such that route relations can be more
> meaningful and accurately describe which track each train uses.
>
> In the course of doing this, I got a tap on the shoulder [1] and found out
> I was using a definition of railway=halt that may not match up with what
> people were expecting. As far as I know now, railway=station was originally
> intended for stations where trains are always scheduled to stop, and
> railway=halt for flag stops (aka request stops). In the German OSM
> community, there was a decision made for railway=halt to be used on
> stations that are missing switches, which means trains cannot switch
> tracks, terminate or reverse direction there—a distinction more relevant to
> railway operations and scheduling. Naturally, there are quite a lot more of
> these than flag stops.
>
> I'm in a predicament here. So far, I've mapped all Amtrak stations and
> various commuter rail stations across the Northeast according to the
> no-switches definition of halt. I'm happy to revert these back to stations
> (wherever they aren't flag stops), though I'd like to hear others' thoughts
> before going through with that.
>
> -Clay
>
> [1] https://www.openstreetmap.org/changeset/77959450
>

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

Re: [Diversity-talk] Diversity 2020 Article

[Marc Gemis]

Would a Code of Conduct also apply to social media that are not
controlled by OSM/OSMF?
E.g. Twitter is currently used by a certain part of the community to
ridicule and criticize people writing on the mailing lists.

regards

m.

On Wed, Jan 8, 2020 at 1:16 AM Clifford Snow  wrote:
>
> https://www.techrepublic.com/article/diversity-why-open-source-needs-to-work-on-it-in-2020/
>  is an interesting read. The article talks about open source, but I don't see 
> any significant difference between an open data project or an open source 
> software project.
>
> What I took away from the article is
>
> We need to be more inclusive
> Men (especially over 45) don't see diversity as an issue
> Younger community members see things getting better
> We need a clear and enforced Code of Conduct to create a welcoming community
> Quotas are not the answer
>
> Just for the record, I'm a while male over (way over) 45.
>
> Happy New Year,
> Clifford
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> 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] JOSM: hover-Coordinate by easy click into clipboard?

[Erwin Olario]

In JOSM, on an active layer, while a node is selected, you can press
CTRL+SHIFT+C and it will copy its coordinates to memory.

On Tue, Jan 7, 2020, 09:43 tshrub  wrote:

> hi,
>
> in JOSM's status bar the mouse position is constantly running as a
> coordinate. Is there any easy way to get it, may be by keyboard into the
> clipboard?
> I want to edit GPS data from, or better: add GPS-data to trackless
> photos - I want to place them like this with JOSM' sat-pictures.
>
> bella saluti
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-au] Fire Station Operators

[Andrew Harvey]

+1 you can use the tag
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dwater_tank
There is also
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dsuction_point but
you'd need local knowledge for these.

On Wed, 8 Jan 2020 at 14:32, Daniel O'Connor 
wrote:

>
>
> On Wed, Jan 8, 2020 at 1:14 PM Andrew Harvey 
> wrote:
>
>> This MapRoulette challange is mostly about adding the operator and
>> operator:wikidata tags and also branch if you can.
>>
>>
> If you do see other attributes like solar (rare), or water tanks (less
> rare); please do map those too.
>
> Map of stations with a solar panel within 50m:
> https://overpass-turbo.eu/s/Py1
>
> Map of stations with a water tank nearby:
> https://overpass-turbo.eu/s/Py2
>
> Those are two bits of infrastructure it's reasonably easy to ask a council
> to look at purchasing; where it makes sense.
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Fire Station Operators

[Daniel O'Connor]

On Wed, Jan 8, 2020 at 1:14 PM Andrew Harvey 
wrote:

> This MapRoulette challange is mostly about adding the operator and
> operator:wikidata tags and also branch if you can.
>
>
If you do see other attributes like solar (rare), or water tanks (less
rare); please do map those too.

Map of stations with a solar panel within 50m:
https://overpass-turbo.eu/s/Py1

Map of stations with a water tank nearby:
https://overpass-turbo.eu/s/Py2

Those are two bits of infrastructure it's reasonably easy to ask a council
to look at purchasing; where it makes sense.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Fire Station Operators

[Andrew Harvey]

I'd normally just leave the name as is it, since the name should be as
signposted which could vary. This MapRoulette challange is mostly about
adding the operator and operator:wikidata tags and also branch if you can.

The branch is usually just the suburb eg. if it's named "Heathcote Fire
Brigade" then "branch=Heathcote", it helps to normalise the name.

I would say let's only map what we know if unsure then skip. Especially
with regards to fire station numbers.

On Wed, 8 Jan 2020 at 13:13, Graeme Fitzpatrick 
wrote:

> Just starting on the Roulette challenge (which is *much* slower than
> fixing phone numbers!:-))
>
> Just want to confirm please, that it should be:
>
> Name=NSW Rural Fire Service (name)
>
> branch=(name) Rural Fire Station - I've seen one so far that's listed as
> Brigade, rather than Station - either / or or one or the other in
> particular?
>
> operator=NSW Rural Fire Service
>
> operator:wikidata=Q7011777
>
>
> name=Fire and Rescue NSW Station (number) (name)
>
> branch=(name) Fire Station
>
> operator=Fire and Rescue NSW
>
> operator:wikidata=Q5451532
>
> In regard to the Station number, does anybody know if the "station" shown
> on the FRNSW site actually means that station, or is it only a random page
> number? eg https://www.fire.nsw.gov.au/page.php?id=9210=24 - is
> Batlow Station 24?
>
>
> One thing I noticed with tagging the area as amenity-fire-station, is that
> it defaults (at least iD does) to building=yes.
>
> If you then add a driveway or similar, without deleting the building=key,
> these will then error, as a driveway can't cross a "building"
>
>
> Thanks
>
> Graeme
>
>
> On Mon, 6 Jan 2020 at 13:31, Graeme Fitzpatrick 
> wrote:
>
>> Fine!
>>
>> The volunteer rural firies certainly do distinguish themselves from the
>> urban professionals!, & their stations are all labelled Rural Fire Brigade,
>> usually with RFS logo, so I'll go with that for rural & QFES for urban, but
>> the same Wikidata tag on both.
>>
>> Thanks
>>
>> Graeme
>>
>>>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Fire Station Operators

[Graeme Fitzpatrick]

Just starting on the Roulette challenge (which is *much* slower than fixing
phone numbers!:-))

Just want to confirm please, that it should be:

Name=NSW Rural Fire Service (name)

branch=(name) Rural Fire Station - I've seen one so far that's listed as
Brigade, rather than Station - either / or or one or the other in
particular?

operator=NSW Rural Fire Service

operator:wikidata=Q7011777


name=Fire and Rescue NSW Station (number) (name)

branch=(name) Fire Station

operator=Fire and Rescue NSW

operator:wikidata=Q5451532

In regard to the Station number, does anybody know if the "station" shown
on the FRNSW site actually means that station, or is it only a random page
number? eg https://www.fire.nsw.gov.au/page.php?id=9210=24 - is
Batlow Station 24?


One thing I noticed with tagging the area as amenity-fire-station, is that
it defaults (at least iD does) to building=yes.

If you then add a driveway or similar, without deleting the building=key,
these will then error, as a driveway can't cross a "building"


Thanks

Graeme


On Mon, 6 Jan 2020 at 13:31, Graeme Fitzpatrick 
wrote:

> Fine!
>
> The volunteer rural firies certainly do distinguish themselves from the
> urban professionals!, & their stations are all labelled Rural Fire Brigade,
> usually with RFS logo, so I'll go with that for rural & QFES for urban, but
> the same Wikidata tag on both.
>
> Thanks
>
> Graeme
>
>>

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

[Talk-us] User in Florida changing several motorways to trunk

[James Mast]

I was just alerted to this by a friend, and thought I'd post about it here as 
well, since I don't really have the time to work on doing all the reverting 
that unfortunately needs to be done here (there's a lot).

But over the last 2 weeks, there's been a user changing several 100% motorways 
(& are toll highways to boot) that just happen to be state highways in Florida 
from motorway to trunk.  This is mostly as far as I can tell in the Orlando 
area, but might affect other areas in FL too.

I did leave the user a message on Changeset 79155661 ( 
https://www.openstreetmap.org/changeset/79155661 ).  Hoping he will see it, but 
with all the major highways that have been seriously demoted in priority that 
could seriously affect routing very badly, I honestly couldn't wait for a 
response before I posted a message to here as well.

Anybody willing to help out here in restoring the motorway tags to the proper 
highways?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Besoin d'aide pour le Parc national de Guadeloupe

[Philippe Verdy]

JOSM émet des alertes au cas où cela serait un doublon, mais ce n'est pas
toujours des "erreurs"; il faut l'intelligence humaine pour comprendre
JOSM se contente juste de la liste des membres, mais n'interprète pas les
tags et leur signification... Bref ne PAS "corriger" tout ce que trouve
JOSM dont l'analyse est partielle.

Le mar. 7 janv. 2020 à 19:02, Yves P.  a écrit :

> Le 1 janv. 2020 à 18:11, Philippe Verdy  a écrit :
>
> Ma *question secondaire était en fait *: Peut-on définir une seule fois
>> la géométrie avec par exemple 1047206
>> ,
>> et inclure cette relation dans 2562137
>> 
>>  ?
>>
>
> Non. Les ways doivent être présentes dans les relations frontières, même
> si ce sont les mêmes membres (car effectivement la région et le département
> se partagent le même territoire ;
>
>
> la Guadeloupe n'a pas fusionné ses deux collectivités, elle s'y est
> opposée par référendum local, donc deux entités, deux objets, deux niveaux
> administratifs pour que l'ensemble des régions et celui des départements
> soit complet en France).
>
>
> Je trouve un cas similaire à La Martinique : Communauté d'agglomération
> du Centre de la Martinique
>  et Fort-de-France
> 
> JOSM râle : « Relations avec les mêmes membres »
>
> —
> Yves
>
> ___
> 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] communes-communautés

[Philippe Verdy]

Je me demande si ce n'est pas lié au fait que Freigné a rejoint la Loire
Atlantique pour rejoindre la commune nouvelle (dont le chef-lieu est en
Loire Atlantique), mais a conservé pour son nouveau statut de commune
déléguée son code SIREN, son code INSEE et son code postal en
Maine-et-Loire... Mais alors pourquoi cela ne concerne pas aussi la commune
(déléguée) de Vritz (au nord de Candé et non à l'ouest, Candé restant en
Maine-et-Loire)?

Je me demande si c'est lié à la définition du "Pôle métropolitain Loire
Angers" (pas une EPCI à fiscalité propre mais un EPCI à statut mixte) et
non pas "Angers métropole" (qui est l'ECPI voisin) ou si un SCoT ne serait
pas à jour pour tenir compte de ce changement. Je vois Freigné pourtant
bien délimité sur layers.openstreetmap.fr (mais il est vrai que ce serveur
ne sait pas gérer les recouvrement d'EPCI multiples, il ne sépare pas les
EPCI à fiscalité propre et les autres EPCI informels comme ici les pôles
métropolitains, les SCoT et autres syndicats mixtes: tout est mélangé sur
cette carte dans la même catégorie "local_authority").

Pourrait-on fixer une règles de tag séparant correctement les EPCI à
fiscalité propre (différents statuts entre CC, CA, CU, métropole et
peut-être bientôt les communes-communautés) et les autres EPCI (y compris
les découpages d'EPCI, comme les pôles de proximité de Nantes Métropole et
les territoires du Grand Paris, et les SCoT et syndicats mixtes) ?

On a bien séparé les syndicats mixtes des parcs naturels (pas gérés comme
"boundary" avec "local_authority"), mais il y en a d'autres (SIVU et SIVOM)
pour les agences de bassin, la gestion des eaux, les déchets, les
transports, l'action sociale ou culturelle, la gestions commune de certains
équipements partagés (pour l'éducation ou la santé), etc (dans des cas où
ce n'est pas pris en charge de façon obligatoire par l'EPCI à FP, et
surtout quand ça déborde de son propre territoire et nécessite une
structure mixte où adhèrent plusieurs EPCI à FP, ou seulement certaines de
ses communes membres si c'est une compétence facultative).



Le mer. 8 janv. 2020 à 01:37, Philippe Verdy  a écrit :

> OK donc c'est une erreur OSM pour la CC existante.
>
> On n'a donc encore aucun cas de commune nouvelle créée en
> "commune-communauté" (comme le prévoit la loi de juillet dernier) et on
> n'en verra pas avant les prochaines élections municipales et
> communautaires, puis des mois pour refondre les SCoT et proposer des
> changements, défusionner des communes nouvelles existantes, pour recréer
> des communes nouvelles avec ce nouveau statut mixte, ou arrêter des CC et
> recréer des communes nouvelles avec ce nouveau statut mixte (certaines
> communes n'y adhérant pas devront rejoindre d'autres EPCI, mais des EPCI
> voisins pourraient voir des communes membres en sortir et adhérer à la
> nouvelle commune-communauté). Je ne vois pas ça arriver avant l'été
> prochain (le temps que les conseils nouvellement formés se décident et
> obtiennent l'approbation de l'Etat sur leur nouveau projet).
>
>
>
>
>
>
> Le mar. 7 janv. 2020 à 22:11, Florent Richard 
> a écrit :
>
>> Bonsoir,
>>
>> Pour le cas des "Vallons de l'Erdre", il s'agit d'une erreur. où as-tu vu
>> que les Vallons de l'Erdre (ou même seulement Freigné) ne serait dans aucun
>> EPCI?
>>
>> Elle fait bien partie dans son intégralité de la Communauté de Commune du
>> Pays d'Ancenis (COMPA) depuis sa création il y a 2 ans.
>> Les sites web de la commune et de la COMPA le précisent bien tous les 2
>> (y compris dans des actualités récentes). https://www.vallonsdelerdre.fr/
>> https://www.pays-ancenis.com/
>> La relation correspondante est correcte dans OSM
>> https://www.openstreetmap.org/relation/535798
>>
>> Dès la création de cette commune nouvelle, elle a fait partie de la
>> COMPA, car la plupart des communes d'origine y étaient déjà.
>> Freigné fait bien partie de cette commune nouvelle et est bien incluse
>> dans la COMPA. Freigné était auparavant dans le département du
>> Maine-et-Loire et a donc été déplacée dans le département de la
>> Loire-Atlantique à cette occasion.
>>
>> Il y a des chances pour que très peu de sources autres qu'OSM et
>> Wikipédia soient à jour sur ce cas. On voit régulièrement que les
>> frontières de la Loire-Atlantique ne sont pas mise à jour dans beaucoup de
>> cartes.
>>
>>
>> Cordialement,
>> Florent RICHARD
>>
>> --
>> *De :* Philippe Verdy 
>> *Envoyé :* mardi 7 janvier 2020 19:08
>> *À :* Discussions sur OSM en français 
>> *Objet :* [OSM-talk-fr] communes-communautés
>>
>> Vous ne l'avez peut-être pas remarqué mais la loi de juillet 2019 permet
>> maintenant à une commune nouvelle de prendre les responsabiltés d'un EPCI à
>> fiscalité propre dès sa création, sans devoir adhérer à un autre EPCI à
>> fiscalité propre.
>>
>> Cela crée le statut de "commune-communauté" mixant à la fois en une seule
>> collectivité l'EPCI et la commune nouvelle comprenant ses communes
>> déléguées. Cela se fait 

Re: [OSM-talk-fr] communes-communautés

[Philippe Verdy]

OK donc c'est une erreur OSM pour la CC existante.

On n'a donc encore aucun cas de commune nouvelle créée en
"commune-communauté" (comme le prévoit la loi de juillet dernier) et on
n'en verra pas avant les prochaines élections municipales et
communautaires, puis des mois pour refondre les SCoT et proposer des
changements, défusionner des communes nouvelles existantes, pour recréer
des communes nouvelles avec ce nouveau statut mixte, ou arrêter des CC et
recréer des communes nouvelles avec ce nouveau statut mixte (certaines
communes n'y adhérant pas devront rejoindre d'autres EPCI, mais des EPCI
voisins pourraient voir des communes membres en sortir et adhérer à la
nouvelle commune-communauté). Je ne vois pas ça arriver avant l'été
prochain (le temps que les conseils nouvellement formés se décident et
obtiennent l'approbation de l'Etat sur leur nouveau projet).






Le mar. 7 janv. 2020 à 22:11, Florent Richard  a
écrit :

> Bonsoir,
>
> Pour le cas des "Vallons de l'Erdre", il s'agit d'une erreur. où as-tu vu
> que les Vallons de l'Erdre (ou même seulement Freigné) ne serait dans aucun
> EPCI?
>
> Elle fait bien partie dans son intégralité de la Communauté de Commune du
> Pays d'Ancenis (COMPA) depuis sa création il y a 2 ans.
> Les sites web de la commune et de la COMPA le précisent bien tous les 2 (y
> compris dans des actualités récentes). https://www.vallonsdelerdre.fr/
> https://www.pays-ancenis.com/
> La relation correspondante est correcte dans OSM
> https://www.openstreetmap.org/relation/535798
>
> Dès la création de cette commune nouvelle, elle a fait partie de la COMPA,
> car la plupart des communes d'origine y étaient déjà.
> Freigné fait bien partie de cette commune nouvelle et est bien incluse
> dans la COMPA. Freigné était auparavant dans le département du
> Maine-et-Loire et a donc été déplacée dans le département de la
> Loire-Atlantique à cette occasion.
>
> Il y a des chances pour que très peu de sources autres qu'OSM et Wikipédia
> soient à jour sur ce cas. On voit régulièrement que les frontières de la
> Loire-Atlantique ne sont pas mise à jour dans beaucoup de cartes.
>
>
> Cordialement,
> Florent RICHARD
>
> --
> *De :* Philippe Verdy 
> *Envoyé :* mardi 7 janvier 2020 19:08
> *À :* Discussions sur OSM en français 
> *Objet :* [OSM-talk-fr] communes-communautés
>
> Vous ne l'avez peut-être pas remarqué mais la loi de juillet 2019 permet
> maintenant à une commune nouvelle de prendre les responsabiltés d'un EPCI à
> fiscalité propre dès sa création, sans devoir adhérer à un autre EPCI à
> fiscalité propre.
>
> Cela crée le statut de "commune-communauté" mixant à la fois en une seule
> collectivité l'EPCI et la commune nouvelle comprenant ses communes
> déléguées. Cela se fait à la création de la commune nouvelle. Cela apporte
> plus de souplesse pour relancer les communes nouvelles (qui autrement ne
> voudraient pas adhérer à une autre intercommunalité limitrophe devenant
> trop grande.
>
> La loi étant passée en juillet 2019 intervient trop tard pour que ce
> dispositif se mette en place avant les prochaines élections
> municipales/intercommunales en mars 2020, donc on n'aura rien avant au
> minimum juillet 2020. Mais sans doute du chambardement avec des défusions
> de communes nouvelles et recréation de nouvelles communes-communauté.
>
> 
>
> Il semble qu'il n'y ait pour l'instant qu'un seul cas bizarre (à moins que
> ce soit une erreur):
>
> Les "Vallons de l'Erdre" à côté de Candé en Maine-et-Loire, dont une
> commune (Freigné) n'est actuellement dans aucun des EPCI voisins déjà très
> grands (Pays d'Ancenis à l'ouest, Anjou Bleu Communauté au nord-est qui
> inclus la ville limitrophe de Candé et celle de Segré son chef-lieu, ou la
> CC de la Vallée du Haut Anjou au sud-est). Pourtant Freigné semble bien
> faire partie des Vallons de l'Erdre en tant que commune déléguée.
>
> La fusion a-t-elle été annulée ou veut-elle changer d'EPCI et rejoindre
> Candé dans Anjou Bleu Communauté?
>
> Veut-elle préserver son caractère rural entre Ancenis/Segré et Angers ; si
> certaines communes déléguées les plus proches d'Ancenis auraient pu
> rejoindre Anjou Bleu Communauté, d'autres se voyaient plus proche du pays
> d'Ancenis et aucune n'était satisfaite de se voir reléguée des services
> entre Segré, Ancenis et Angers, trois chef-lieux trop loin des
> préoccupation de cette communauté rurale.
>
> Il faut dire que les EPCI de Maine-et-Loire ont été faits "à l'arrache" et
> sont les plus grands du territoire métropolitain et cela a conduit à une
> centralisation plus ou moins "forcée" vers un nombre plus restreint de
> pôles urbains et des tas de maires ruraux mécontents du sort qu'on leur
> fait et de la disparition contrainte de services de proximité et une
> planification renforçant le poids des centres urbains sur tout le reste
> (aménagement, transports, services sociaux, services fiscaux,
> police/gendarmerie, établissements culturels et sportifs, écoles 

Re: [OSM-talk-fr] adresse mail rejetée

[Philippe Verdy]

Pour ceux auxquels je réponds, cela dépend du message source : si je reçois
par l'adresse @wanadoo.fr et je fais "répondre", l'expéditeur sera cette
adresse, même quand j'utilise gmail.

Au début je n'avais QUE l'adresse wanadoo (maintenant orange), mais c'est
en voyant que je ne recevais plus certains messages (comportement incorrect
des serveurs d'Orange pas tous correctement déclarés dans les DNS et pas
traçables/authentifiables), que j'ai du inscrire ma seconde adresse gmail
sur cette liste (je ne l'ai fait nulle part ailleurs sur aucune autre liste
que les listes OSM qui ont ce bogue et gèrent mal le suivi du routage et
corrompent certains protocoles, en plus du fait qu'Orange lui aussi fait un
routage bizarre pendant ses transferts SMTP internes via des serveurs
anonymes non déclarés, qui font que la chaine des "received: from" est
totalement invérifiable car la chaine est brisée; Orange n'est pas le seul
à avoir ce problème qui existe aussi à La Poste, et chez Free; et les FAI
français ont tous des problèmes de conformité ou de stabilité sur leurs
serveurs; Orange n'est pas non plus totalement conforme à DMARC ou ce
qu'exigent maintenent Gmail, Yahoo et d'autres, à cause des filtres
antispam qui sont plus stricts en terme de protocole).

Il se trouve que les listes d'OSM utilisent un logiciel gestionnaire qui
n'adhère pas aux recommandations récentes, et il se fait régulièrement
bloquer par divers services qui rejettent les mails, la liste OSM
corrompant aussi la chaine de suivi. Ce gestionnaire de listes est vieux et
pas à jour et les admins d'OSM ne sont pas prêts à changer les choses : il
reçoit des bounces à cause de ça, et désabonne les gens sans prévenir au
lieu de corriger. Maintenir un gestionnaire privé est difficile
techniquement et OSM n'a pas la réelle capacité technique de suivre les
changements nécessaires. C'est pour ça que la plupart des mailing lists
utilisent des fournisseurs spécialisés dont c'est le métier de voir ce qui
coince. Mais les admins d'OSM n'ont pas réellement le temps de suivre ça.



Le mar. 7 janv. 2020 à 21:56, marc marc  a
écrit :

> Philippe ce n'est pas le cas, tous tes emails
> sont en verd...@wanadoo.fr, ci dessous les entêtes
> de celui auquel je répond.
>
> j'ai aussi mis en dessous le nouveau thread
> que tu as créés aujourd'hui.
>
> Je te sugère de désabonner l'email wanadoo
> pour ne garder que l'abo en gmail.com
> ansi le problème cessera de lui-même.
>
>  Message transféré 
> Sujet : Re: [OSM-talk-fr] adresse mail rejetée
> Date :  Tue, 7 Jan 2020 18:17:58 +0100
> De :Philippe Verdy 
>
> 
> Pour les nouveaux messages à la liste, j'envoie maintenant
> avec mon adresse Gmail
> 
>
>  Message transféré 
> Sujet : [OSM-talk-fr] communes-communautés
> Date :  Tue, 7 Jan 2020 19:08:33 +0100
> De :Philippe Verdy 
> ___
> 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-us] Railway improvements; stations vs. halts

[Clay Smalley]

Hi all,

Over the last few months, I've been doing some systematic improvements to
the passenger railway network across North America. Much of this has been
filling out public_transport=stop_area relations for every railway station,
including stop positions and platforms, as well as verifying the geometry
of the underlying railways and classifying them (usage=*, service=*). My
goal here is to prepare the map such that route relations can be more
meaningful and accurately describe which track each train uses.

In the course of doing this, I got a tap on the shoulder [1] and found out
I was using a definition of railway=halt that may not match up with what
people were expecting. As far as I know now, railway=station was originally
intended for stations where trains are always scheduled to stop, and
railway=halt for flag stops (aka request stops). In the German OSM
community, there was a decision made for railway=halt to be used on
stations that are missing switches, which means trains cannot switch
tracks, terminate or reverse direction there—a distinction more relevant to
railway operations and scheduling. Naturally, there are quite a lot more of
these than flag stops.

I'm in a predicament here. So far, I've mapped all Amtrak stations and
various commuter rail stations across the Northeast according to the
no-switches definition of halt. I'm happy to revert these back to stations
(wherever they aren't flag stops), though I'd like to hear others' thoughts
before going through with that.

-Clay

[1] https://www.openstreetmap.org/changeset/77959450
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-vi] AI Assisted Road Mapping

[Jeff Underwood]

Hi all,



I'm Jeff, a GIS analyst leading the map editing team at Facebook.



We are wrapping up our work in Malaysia and are planning to do some mapping in 
Vietnam in the near future and would like to inform the community of the 
activity.



We will be mapping missing roads using our AI assisted mapping tool, RapiD. You 
can read some more about it at our site http://mapwith.ai/ and give it a try 
yourself. Our Github explains the mapping process well for those that haven't 
tried it before. 
https://github.com/facebookmicrosites/Open-Mapping-At-Facebook/wiki



You can visit our OSM wiki page to view our past projects at 
https://wiki.openstreetmap.org/wiki/Facebook_AI-Assisted_Road_Tracing





If there is any local road tagging schemas or tricky situations we should look 
out for, I would love to hear about them.



I'm happy to answer any questions here or you can email us directly at 
o...@fb.com.



Thanks for your time!
Jeff

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

[Diversity-talk] Diversity 2020 Article

[Clifford Snow]

https://www.techrepublic.com/article/diversity-why-open-source-needs-to-work-on-it-in-2020/
is
an interesting read. The article talks about open source, but I don't see
any significant difference between an open data project or an open source
software project.

What I took away from the article is

   - We need to be more inclusive
   - Men (especially over 45) don't see diversity as an issue
   - Younger community members see things getting better
   - We need a clear and enforced Code of Conduct to create a welcoming
   community
   - Quotas are not the answer

Just for the record, I'm a while male over (way over) 45.

Happy New Year,
Clifford

-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [talk-au] Delivery Status Notification (Failure)

[Graeme Fitzpatrick]

Now here's an interesting one ...

Just went into Map Roulette to check out the new challenges that Andrew
mentioned, & the number formatting for NSW popped up, despite me finishing
it a couple of days ago?

https://maproulette.org/browse/challenges/4406

It now says 96% complete with 15 still to do, with tasks from yesterday?

Thanks

Graeme


> On 06/01/20 18:25, Graeme Fitzpatrick wrote:
> > & NSW is done! :-)
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[OSM-talk-fr] Abus de StephaneP : adresses FANTOIR

[Philippe Verdy]

Voir son commentaire:
https://www.openstreetmap.org/changeset/79302148#map=19/47.08243/-1.33683

Visiblement il n'a pas compris le FANTOIR et supprime les adresses et crée
des trucs "à sa sauce".
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adresse mail rejetée

[marc marc]

Le 08.01.20 à 00:04, Christian Quest a écrit :
> Certes, mais ceci devrait arriver sur toutes les ML... or il n'y a que
> sur talk-fr que je suis (et pas tout seul) régulièrement désabonné pour
> cause bounce.

le premier cas (nombreux email @yahoo.fr émis depuis les serveurs gmail)
n'est apparement pas si courant :)
et/ou les autres listes ont la protection dmnarc activitée
comme la liste tech par ex
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adresse mail rejetée

[Christian Quest]

Le 07/01/2020 à 16:52, marc marc a écrit :

Bonjour,

J'ai discuté avec TomH ce midi. Le soucis semble être double :

- certains email sont protégé par spf et/ou dmarc,
une technologique qui permet de préciser qui a le droit d'envoyer
un email avec tel domaine ou tel serveur/ip.
les listes de diffusion cassent cette protection (pour le destinataire,
l'email n’apparaît plus comme venant de l'expéditeur d'origine mais
comme venant d'un serveur sans rapport avec le domaine initial).
Certains domaines de destination sont stricts sur ce critère,
ce qui provoque un bounce et une fois atteint x bounce, le serveur de
liste désinscrit ce destinataire.
une modification a été faite à ce sujet pour modifier ces emails et
mettre talk-fr comme expéditeur à la place (cfr mon email de 16h05
comme exemple).
cependant mon email suivant n'a pas été masqué, donc p'tre qu'il
reste un problème.

- certains domaines de destination ne semble pas aimer les emails
redirigé. en effet ils reçoivent par exemple un email @wanadoo.fr
avec l'ip d'un serveur qui n'est pas celui de wanadoo mais gmail.
ils peuvent considérer cela comme de l'usurpation classique des spam.
dans les logs, le serveur free.fr répond par exemple "550 spam detected"
Pour résoudre cela, soit il faut demander à free.fr d'être moins strict
(quasi aucune chance d'aboutir) soit les utilisateurs inscrits via un
domaine mais qui transmettent cet email à un autre hébergeur devrait
cesser ce le faire et s'inscrire directement avec cet autre hébergeur.
les différents cas trouvé par TomH pour talk-fr concerne tous Philippe
Verdy mais il n'a pas faire une analyse complète, donc si d'autres sont
dans le cas, n'hésitez pas à signaler/migrer :)

Cordialement,
Marc
___



Certes, mais ceci devrait arriver sur toutes les ML... or il n'y a que 
sur talk-fr que je suis (et pas tout seul) régulièrement désabonné pour 
cause bounce.


Je n'ai jamais eu à réactiver un abonnement sur les autres.


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk] mapping outside Europe

[Pierre Béland via talk]

Eh, I am quite please to realise that the page is now available in 6 languages.

The  first version of the page early 2013 was for the OpenStreetMap response 
North of Mali. But in later discussions, contributors did say that it did also 
represent reality of other African countries. We then collectively decided to 
rename it to highway_tag_africa. 

There are regular mentions on discussion lists about this classification but no 
success using search tools to find references. I will let local contributors 
from various countries respond to your questions about classification and name 
to use.
In one country, the situation can vary a lot from more urban and industrialized 
regions to other regions.  I can tell you that north of Quebec / Canada there 
are vast forestry areas with very low population. Road infrastructures in such 
forestry areas are quite different from the urban areas and I would not 
classify a few hundred km long unpaved and rough road interconnecting various 
other roads as track.See for example the transtaiga highway 
https://www.openstreetmap.org/relation/6625883#map=7/54.104/-73.644
 Pierre 
 

Le mardi 7 janvier 2020 16 h 38 min 39 s UTC−5, Mario Frasca 
 a écrit :  
 
 On 07/01/2020 15:46, Pierre Béland wrote:
> I am the original author of the Highway Africa Tag wiki page.  This 
> page is now widely used outside of Africa (Asia and Latin-America) in 
> areas where it better correspond to the reality of the roads 
> infrastructure.

I see, and I like it.  good job!

but it still only mentions 'Africa'.  How would you describe the 
application range, other than "outside high wages / developed countries"?

my guess for the first sentence would be "Most regions in the world do 
not show the same road network quality as, say, Germany or Canada.  Road 
conditions in such regions do not match the economic and social role of 
the road." then go on with the rest.

which Latin American countries are using this page as a reference? as 
far as you and others here know?
> And pictures have been used to better correspond to the ligther road 
> structures in these areas, which are often unpaved. 

nice pictures indeed.  curious enough, they aren't (yet) linked in the 
Spanish version of the page.  I might find time to do so.

ciao,

MF

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

Re: [talk-au] Over 55?s Lifestyle Village = retirement_home ?

[forster]

Hi

Here is a site transitioning from a caravan park
https://www.ingeniaholidays.com.au/albury/

to a 55+ lifestyle village
https://ingenialifestyle.com.au/communities/nsw/regional-nsw/albury

The whole area is currently tagged as a tourism = caravan_site
https://www.openstreetmap.org/way/338714438

Here is a resort which shares many of the features of a 55+ village
http://www.moamaonmurray.com.au/
Node currently tagged as a leisure=resort (and not rendering)
https://www.openstreetmap.org/node/6442022046

I found the proposal
https://wiki.openstreetmap.org/wiki/Proposed_features/Trailer_Park
which notes that many demountable villages are tagged place=hamlet

These existing tags could be used
(from https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dcamp_site)
tents = yes/no
caravans = yes/no
cabins = yes/no
static_caravans = yes/no
permanent_camping = yes/no/only

There could be a new tag
demountable =yes/no

Tony



I can confirm these observations for another similar site I've visited.

On 7 January 2020 7:30:48 am AEDT, fors...@ozonline.com.au wrote:

Hi
Looking at the photos and site plan I suspect the homes may be
demountable, that is, on temporary foundations. Sorry , I am not
directly answering the tagging question, Even if purpose built it may
effectively be a caravan park with all the sites taken by onsite
cabins. Typically the site is leased but the building is owned by the
resident.

They allow for greater density than strata plan units. The demountable

construction allows the fiction that these buildings could ever be
moved.

Tony



Hi all,

is a Over 55?s Lifestyle Village (like this one
https://www.middlerockhomevillage.com.au) a amenity=retirement_home?

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dretirement_home

I'm not clear if the Lifestyle Village is only a fancy marketing name

or

not. I've seen such villages and some are past caravan parks that

have

been re-purposed with the over 55's as clientel.

How would you tag this?


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

_
This mail has been virus scanned by Australia On Line
see http://www.australiaonline.net.au/mailscanning







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


_
This mail has been virus scanned by Australia On Line
see http://www.australiaonline.net.au/mailscanning







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

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[marc marc]

Le 07.01.20 à 16:54, Philippe Verdy a écrit :
> pour les routes (sur la voie publique) on n'a pas besoin de clé car il
> n'y a à priori qu'un opérateur public attitré localement

il y a le national, le départemental, le communal, les concessions
d'autoroute et dans d'autres pays, il y a encore d'autres cas.
ce n'est donc pas cela la raison, la raison est franco-française :
on a en france qlq passionés des espaces de noms au point qu'on
en rajoute encore et encore parce que "d'autres l'ont fait".

si on veux distinguer les opérateurs ou les réseaux,
il y a les clefs qu'il faut pour.
quand je map un power=substation hors de France,
je n'ai pas besoin de wiki et pas besoin d'altérer le résultat
de mon éditeur, je met la ref dans ref et c'est terminé.

Le 07.01.20 à 17:05, Yves P. a écrit :
> si on ne connait pas la ref:* à mettre, on peut mettre ref

bien évidemenmt. mais elle serra invisible pour ceux qui ciblent
les ref:FR:xxx

Le 07.01.20 à 17:05, Yves P. a écrit :
> Les intérêts sont :
>
>   * de lier l’objet OSM à un objet dans une base de donnée externe.

c'est tout autant lié avec ref

>   * pour un objet qui a plusieurs références, de les différencier.

hors France, il y a aussi des objets multi-référence (dont les routes)
cela ne les empeches pas d'avoir comme règle de base d'utiliser ref
et de préciser la clef quand il y a besoin et non comme règle de base

>   * pour une machine (voir un humain), de savoir à quoi ça correspond.
> Référence de l’opérateur, de la commune… ?

on fait pareil avec name ? remplacer par défaut name=truc
par name:lenomdelentitiéquiadefinitlenom=truc ?
c'est compréhensible de vouloir être précis mais c'est nuisible d'en
faire un règle de clef par défaut.

je pense qu'il n'est pas du rôle d'osm de devoir
connaitre qui a définit la ref lisible sur plaque comme prérequis
pour l'ajouter correctement dans osm.
j'en reviens avec l'analogie des routes, on utilise ref pour la
référence principale sans se soucier si la ref a été définie
par la commune ou par le niveau national.
Et uniquement quand il y a plusieurs ref, on fait une règle
pour les autres ref. idem pour les noms, idem pour tout.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] mapping outside Europe

[Mario Frasca]

On 07/01/2020 15:46, Pierre Béland wrote:
I am the original author of the Highway Africa Tag wiki page.  This 
page is now widely used outside of Africa (Asia and Latin-America) in 
areas where it better correspond to the reality of the roads 
infrastructure.


I see, and I like it.  good job!

but it still only mentions 'Africa'.  How would you describe the 
application range, other than "outside high wages / developed countries"?


my guess for the first sentence would be "Most regions in the world do 
not show the same road network quality as, say, Germany or Canada.  Road 
conditions in such regions do not match the economic and social role of 
the road." then go on with the rest.


which Latin American countries are using this page as a reference? as 
far as you and others here know?
And pictures have been used to better correspond to the ligther road 
structures in these areas, which are often unpaved. 


nice pictures indeed.  curious enough, they aren't (yet) linked in the 
Spanish version of the page.  I might find time to do so.


ciao,

MF


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

[Talk-us] USFS trail/road/route numbers

[Tod Fitch]

In my area there seems to be a mix of how the US Forest Service route numbers 
are tagged on roads and trails. The main variations seem to be:

name=“Forest Route 9N24”
name=“FR 9N24”
alt_name=“Forest Route 9N24”
alt_name=“FR 9N24”
ref=“FR 9N24”
ref=“9N24”

Things I’ve seen in the wiki that might pertain cover “National Forest Trails” 
[1] which seems to want a tag of “route_no” or “trail_no”. That just seems 
wrong.

And in the United States roads tagging [2] which seems to prefer tagging like:

ref=“NFR 9N24”

Which I don’t recall seeing in my area.

What should the preferred tagging be? My inclination would be to migrate the 
tagging in my area toward that listed on the US road tagging page (e.g. 
ref=“NFR 9N24”) even though my preference (for printed map display purposes) 
would be to simply use ref=“9N24”.

Opinions?

Thanks!
Tod

[1] 
https://wiki.openstreetmap.org/wiki/US_Forest_Service_Data#National_Forest_Trails
[2] 
https://wiki.openstreetmap.org/wiki/United_States_roads_tagging#National_forest_primary_routes


signature.asc
Description: Message signed with OpenPGP
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] communes-communautés

[Florent Richard]

Bonsoir,

Pour le cas des "Vallons de l'Erdre", il s'agit d'une erreur. où as-tu vu que 
les Vallons de l'Erdre (ou même seulement Freigné) ne serait dans aucun EPCI?

Elle fait bien partie dans son intégralité de la Communauté de Commune du Pays 
d'Ancenis (COMPA) depuis sa création il y a 2 ans.
Les sites web de la commune et de la COMPA le précisent bien tous les 2 (y 
compris dans des actualités récentes). https://www.vallonsdelerdre.fr/ 
https://www.pays-ancenis.com/
La relation correspondante est correcte dans OSM 
https://www.openstreetmap.org/relation/535798

Dès la création de cette commune nouvelle, elle a fait partie de la COMPA, car 
la plupart des communes d'origine y étaient déjà.
Freigné fait bien partie de cette commune nouvelle et est bien incluse dans la 
COMPA. Freigné était auparavant dans le département du Maine-et-Loire et a donc 
été déplacée dans le département de la Loire-Atlantique à cette occasion.

Il y a des chances pour que très peu de sources autres qu'OSM et Wikipédia 
soient à jour sur ce cas. On voit régulièrement que les frontières de la 
Loire-Atlantique ne sont pas mise à jour dans beaucoup de cartes.


Cordialement,
Florent RICHARD


De : Philippe Verdy 
Envoyé : mardi 7 janvier 2020 19:08
À : Discussions sur OSM en français 
Objet : [OSM-talk-fr] communes-communautés

Vous ne l'avez peut-être pas remarqué mais la loi de juillet 2019 permet 
maintenant à une commune nouvelle de prendre les responsabiltés d'un EPCI à 
fiscalité propre dès sa création, sans devoir adhérer à un autre EPCI à 
fiscalité propre.

Cela crée le statut de "commune-communauté" mixant à la fois en une seule 
collectivité l'EPCI et la commune nouvelle comprenant ses communes déléguées. 
Cela se fait à la création de la commune nouvelle. Cela apporte plus de 
souplesse pour relancer les communes nouvelles (qui autrement ne voudraient pas 
adhérer à une autre intercommunalité limitrophe devenant trop grande.

La loi étant passée en juillet 2019 intervient trop tard pour que ce dispositif 
se mette en place avant les prochaines élections municipales/intercommunales en 
mars 2020, donc on n'aura rien avant au minimum juillet 2020. Mais sans doute 
du chambardement avec des défusions de communes nouvelles et recréation de 
nouvelles communes-communauté.



Il semble qu'il n'y ait pour l'instant qu'un seul cas bizarre (à moins que ce 
soit une erreur):

Les "Vallons de l'Erdre" à côté de Candé en Maine-et-Loire, dont une commune 
(Freigné) n'est actuellement dans aucun des EPCI voisins déjà très grands (Pays 
d'Ancenis à l'ouest, Anjou Bleu Communauté au nord-est qui inclus la ville 
limitrophe de Candé et celle de Segré son chef-lieu, ou la CC de la Vallée du 
Haut Anjou au sud-est). Pourtant Freigné semble bien faire partie des Vallons 
de l'Erdre en tant que commune déléguée.

La fusion a-t-elle été annulée ou veut-elle changer d'EPCI et rejoindre Candé 
dans Anjou Bleu Communauté?

Veut-elle préserver son caractère rural entre Ancenis/Segré et Angers ; si 
certaines communes déléguées les plus proches d'Ancenis auraient pu rejoindre 
Anjou Bleu Communauté, d'autres se voyaient plus proche du pays d'Ancenis et 
aucune n'était satisfaite de se voir reléguée des services entre Segré, Ancenis 
et Angers, trois chef-lieux trop loin des préoccupation de cette communauté 
rurale.

Il faut dire que les EPCI de Maine-et-Loire ont été faits "à l'arrache" et sont 
les plus grands du territoire métropolitain et cela a conduit à une 
centralisation plus ou moins "forcée" vers un nombre plus restreint de pôles 
urbains et des tas de maires ruraux mécontents du sort qu'on leur fait et de la 
disparition contrainte de services de proximité et une planification renforçant 
le poids des centres urbains sur tout le reste (aménagement, transports, 
services sociaux, services fiscaux, police/gendarmerie, établissements 
culturels et sportifs, écoles et lycées, santé) et la désertification des 
campagnes qu'on prive de services essentiels et oblige à de longs déplacements 
(en voiture, faute de transport public cohérent et de liaisons que les petites 
communes rurales ne peuvent pas décider au sein des "EPCI géants" de 
Maine-et-Loire).

Verra-t-on du changement ailleurs ?

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

Re: [OSM-talk-fr] adresse mail rejetée

[marc marc]

Philippe ce n'est pas le cas, tous tes emails
sont en verd...@wanadoo.fr, ci dessous les entêtes
de celui auquel je répond.

j'ai aussi mis en dessous le nouveau thread
que tu as créés aujourd'hui.

Je te sugère de désabonner l'email wanadoo
pour ne garder que l'abo en gmail.com
ansi le problème cessera de lui-même.

 Message transféré 
Sujet : Re: [OSM-talk-fr] adresse mail rejetée
Date :  Tue, 7 Jan 2020 18:17:58 +0100
De :Philippe Verdy 


Pour les nouveaux messages à la liste, j'envoie maintenant
avec mon adresse Gmail


 Message transféré 
Sujet : [OSM-talk-fr] communes-communautés
Date :  Tue, 7 Jan 2020 19:08:33 +0100
De :Philippe Verdy 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] mapping outside Europe

[Pierre Béland via talk]

Hi Mario
I am the original author of the Highway Africa Tag wiki page.  This page is now 
widely used outside of Africa (Asia and Latin-America) in areas where it better 
correspond to the reality of the roads infrastructure.  And pictures have been 
used to better correspond to the ligther road structures in these areas, which 
are often unpaved.  

This image near Butembo, North of Democratic Republic of Congo, cleary shows 
damages to road structures at rainy season. I have experienced the same in 
south-east of Haiti, and observed it often in other countries.

https://twitter.com/pierzen/status/1163096946300653570
There is quite a difference between crowdmapping and community mapping. It is 
easy to bring in thousand of inexperienced contributors. But, if  they are not 
trained and monitored, there will be significant damages to the map.
 regard

Pierre 
 

Le mardi 7 janvier 2020 15 h 05 min 38 s UTC−5, Mario Frasca 
 a écrit :  
 
 On 07/01/2020 14:53, Mario Frasca wrote:
> so you say: just revolutionize the overview for the highway tag, 
> without first reaching a consensus?  or I understood you wrong? or 
> replace the Eurocentric pictures with Panama and Morocco pics? an edit 
> like this will be reverted after 15 minutes! 

ah, no, I see, you suggest to take inspiration from the 
https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa, or the German 
(very complete) overview How-to-map-a.  both pages which I did not know.

quite a bit of work, but who knows we manage to motivate the Latam group 
for this.

will put it on my personal to-do list, but if others from Latam are 
reading here, they can add their comments and ideas.

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

Re: [OSM-talk] mapping outside Europe

[Mario Frasca]

On 07/01/2020 14:53, Mario Frasca wrote:
so you say: just revolutionize the overview for the highway tag, 
without first reaching a consensus?  or I understood you wrong? or 
replace the Eurocentric pictures with Panama and Morocco pics? an edit 
like this will be reverted after 15 minutes! 


ah, no, I see, you suggest to take inspiration from the 
https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa, or the German 
(very complete) overview How-to-map-a.  both pages which I did not know.


quite a bit of work, but who knows we manage to motivate the Latam group 
for this.


will put it on my personal to-do list, but if others from Latam are 
reading here, they can add their comments and ideas.


MF




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

Re: [OSM-talk] mapping outside Europe

[Mario Frasca]

On 07/01/2020 14:38, Marc Gemis wrote:

Since OSM is a do-ocracy, do not complain, but write the wiki page you
want to see


that's fine, and I've been doing that for Panama, and for Morocco, but I 
do not like mapping without having reached a consensus.


for that, we need other mappers to contribute to the discussion, and I 
never managed to get any far on this in the wiki (actually, not even in 
the changeset comments).  in particular Panama, none of the local 
mappers seem to use the wiki, just check the authorship statistics.  I'm 
not complaining, I'm stating an observed fact.  there's cultures where 
reading is more common than in others.  I'm generalizing, which will 
always have counterexamples, but if you ask children here (Latin 
America) about a fairy tale, if they know it, they will tell you if they 
have **seen** it, not read it.


so you say: just revolutionize the overview for the highway tag, without 
first reaching a consensus?  or I understood you wrong? or replace the 
Eurocentric pictures with Panama and Morocco pics? an edit like this 
will be reverted after 15 minutes!


MF


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

[Talk-at] Mapathon Salzburg - 23.Jänner

[Jakob Miksch]

Hallo Allerseits,

am Donnerstag den 23.Jänner veranstalten wir in Salzburg einen Mapathon. 
Alle Infos dazu gibt es auf unserer Website: 
http://maptime.io/salzburg/2020/01/23/mapathon/ Jede*r ist herzlich 
willkommen!


Viele Grüße,
Jakob



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

Re: [OSM-talk] mapping outside Europe

[Marc Gemis]

> a more important issue (I would call it "mapping outside Europe", hence
> the subject) is for me each and every (photo)graphic explanation of the
> tagging values.  take `highway`
> (https://wiki.openstreetmap.org/wiki/Key:highway).  text are fine,
> really, but the associated pictures seem all taken in Europe, or North
> America, they have more chances to confuse the mapper based in Africa or
> South America, than helping them.

Problems such as this are easily solved by creating wiki pages for
certain areas, such as
https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa

The Flemish-speaking community created
https://wiki.openstreetmap.org/wiki/NL:How_to_map_a (inspired by the
German https://wiki.openstreetmap.org/wiki/DE:How_to_map_a). We also
have dedicated pages such as
https://wiki.openstreetmap.org/wiki/NL:Jaagpad to explain typical
Belgian/Flemish situations.

Since OSM is a do-ocracy, do not complain, but write the wiki page you
want to see. As soon as you start a group of pages in a certain
language, you might get more people on board.

regards

m.

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

[OSM-talk-fr] communes-communautés

[Philippe Verdy]

Vous ne l'avez peut-être pas remarqué mais la loi de juillet 2019 permet
maintenant à une commune nouvelle de prendre les responsabiltés d'un EPCI à
fiscalité propre dès sa création, sans devoir adhérer à un autre EPCI à
fiscalité propre.

Cela crée le statut de "commune-communauté" mixant à la fois en une seule
collectivité l'EPCI et la commune nouvelle comprenant ses communes
déléguées. Cela se fait à la création de la commune nouvelle. Cela apporte
plus de souplesse pour relancer les communes nouvelles (qui autrement ne
voudraient pas adhérer à une autre intercommunalité limitrophe devenant
trop grande.

La loi étant passée en juillet 2019 intervient trop tard pour que ce
dispositif se mette en place avant les prochaines élections
municipales/intercommunales en mars 2020, donc on n'aura rien avant au
minimum juillet 2020. Mais sans doute du chambardement avec des défusions
de communes nouvelles et recréation de nouvelles communes-communauté.



Il semble qu'il n'y ait pour l'instant qu'un seul cas bizarre (à moins que
ce soit une erreur):

Les "Vallons de l'Erdre" à côté de Candé en Maine-et-Loire, dont une
commune (Freigné) n'est actuellement dans aucun des EPCI voisins déjà très
grands (Pays d'Ancenis à l'ouest, Anjou Bleu Communauté au nord-est qui
inclus la ville limitrophe de Candé et celle de Segré son chef-lieu, ou la
CC de la Vallée du Haut Anjou au sud-est). Pourtant Freigné semble bien
faire partie des Vallons de l'Erdre en tant que commune déléguée.

La fusion a-t-elle été annulée ou veut-elle changer d'EPCI et rejoindre
Candé dans Anjou Bleu Communauté?

Veut-elle préserver son caractère rural entre Ancenis/Segré et Angers ; si
certaines communes déléguées les plus proches d'Ancenis auraient pu
rejoindre Anjou Bleu Communauté, d'autres se voyaient plus proche du pays
d'Ancenis et aucune n'était satisfaite de se voir reléguée des services
entre Segré, Ancenis et Angers, trois chef-lieux trop loin des
préoccupation de cette communauté rurale.

Il faut dire que les EPCI de Maine-et-Loire ont été faits "à l'arrache" et
sont les plus grands du territoire métropolitain et cela a conduit à une
centralisation plus ou moins "forcée" vers un nombre plus restreint de
pôles urbains et des tas de maires ruraux mécontents du sort qu'on leur
fait et de la disparition contrainte de services de proximité et une
planification renforçant le poids des centres urbains sur tout le reste
(aménagement, transports, services sociaux, services fiscaux,
police/gendarmerie, établissements culturels et sportifs, écoles et lycées,
santé) et la désertification des campagnes qu'on prive de services
essentiels et oblige à de longs déplacements (en voiture, faute de
transport public cohérent et de liaisons que les petites communes rurales
ne peuvent pas décider au sein des "EPCI géants" de Maine-et-Loire).

Verra-t-on du changement ailleurs ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Besoin d'aide pour le Parc national de Guadeloupe

[Yves P.]

> Le 1 janv. 2020 à 18:11, Philippe Verdy  a écrit :
> 
> Ma question secondaire était en fait : Peut-on définir une seule fois la 
> géométrie avec par exemple 1047206 
> , et 
> inclure cette relation dans 2562137 
>  ?
> 
> Non. Les ways doivent être présentes dans les relations frontières, même si 
> ce sont les mêmes membres (car effectivement la région et le département se 
> partagent le même territoire ;

> la Guadeloupe n'a pas fusionné ses deux collectivités, elle s'y est opposée 
> par référendum local, donc deux entités, deux objets, deux niveaux 
> administratifs pour que l'ensemble des régions et celui des départements soit 
> complet en France).

Je trouve un cas similaire à La Martinique : Communauté d'agglomération du 
Centre de la Martinique  et 
Fort-de-France 
JOSM râle : « Relations avec les mêmes membres »

—
Yves

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

Re: [OSM-talk-fr] 1ere mondiale (enfin je crois) : le réseau de transport électrique français est routable

[Jacques Lavignotte]

Bravo François.


Le 07/01/2020 à 02:05, François Lacombe a écrit :



Bref, c'est vraiment super
A bientôt !

François

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



--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
On mangera ? (c) (tm)

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

Re: [OSM-talk-fr] 1ere mondiale (enfin je crois) : le réseau de transport électrique français est routable

[Vincent Privat]

Félicitations \o/

Le mar. 7 janv. 2020 à 18:50, David Marchal  a écrit :

> Bravo pour le boulot, François ! C’est parfois une plaie de dénouer les
> lignes, même avec les données de RTE.
>
> Cordialement.
>
> Le 7 janv. 2020 à 02:05, François Lacombe  a
> écrit :
>
> Salut à tous
>
> Mon 1er mail de 2020 ici, donc bonne année à tous !
> Que vos projets respectifs se concrétisent et surtout que vous y trouviez
> une satisfaction sans cesse renouvelée
>
> Pour bien commencer, j'attire votre attention sur le changeset suivant :
> https://www.openstreetmap.org/changeset/79224080
>
> Il marque une étape importante dans la description du réseau de transport
> électrique, débutée dès 2008 je crois
> L'ensemble des tensions 400kV et 225kV sont désormais routables en France,
> via l'emploi de + de 1500 relations cousues-main comme celles-ci
> https://www.openstreetmap.org/relation/6194774
> Elles représentent une continuité métallique avec plusieurs extrémités
> parfois. C'est expliqué ici :
>
> https://wiki.openstreetmap.org/wiki/Power_networks/France#Circuits_et_routage_sur_le_r.C3.A9seau
> Il ne me semble pas que pareil niveau ait été atteint ailleurs dans le
> monde.
> http://overpass-turbo.eu/s/yUw
>
> Le projet a été assorti de la description des postes extrémités, jusqu'aux
> arbres et places de parking
> https://twitter.com/InfosReseaux/status/1210984860292206599?s=20
>
> La complétude va permettre d'extraire une dizaine de jeux de données
> thématiques, dont la plupart n'a pas d'équivalent en données ouvertes, dans
> les prochaines semaines et de communiquer sur leur disponibilité.
> On pourra parler :
> - De la centaine de personnes ayant contribué de ~2008 jusqu'à maintenant
> - Des milliers de km et de photos fait sur le terrain
> - Des dizaines de milliers de km de lignes tracées sur vues aériennes
> (avant la dispo de l'opendata RTE)
> - Des 1200 transformateurs de puissance traqués et positionnés
> - Des dizaines d'hectares de pelouse tracées dans les postes (peut
> directement servir à la planification de l'emploi de moutons chez RTE pour
> limiter l'usage de produits phytosanitaires)
> - Des milliers de km de jeux de barres, portiques, murs, voirie routière
> tracés dans les mêmes postes
> - Des centaines d'arbres positionnés (il me semble)
>
> + probablement d'autres stats
>
> Bref, c'est vraiment super
> A bientôt !
>
> François
> ___
> 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] BD Ortho down... donc UP du plan B

[David Marchal]

Ah, c’était donc ça. Bravo pour la réactivité, Christian !

> Le 7 janv. 2020 à 14:43, Christian Quest  a écrit :
> 
> Le 07/01/2020 à 13:58, Christian Quest a écrit :
>> Les appels de notre proxy à la BD Ortho sont rejetés (403 problème 
>> d'authentification).
>> 
>> Comme le site "pro" de l'IGN est indisponible depuis une dizaine de jours 
>> pour cause de migration version un futur nouveau site plus mieux, impossible 
>> d'aller voir ce qui coince, si il y a une clé à mettre à jour ou autre.
>> 
>> En attendant, je redirige les requêtes vers la couche "tous_fr" de 
>> wms.openstreetmap.fr
>> 
>> Elle ne couvre pas toute la France mais c'est mieux que rien du tout.
>> 
> 
> Rectificatif... l'IGN ne répond plus en HTTP mais uniquement en HTTPS et 
> redirige les requêtes, que le proxy ne suivait pas. C'est désormais corrigé 
> et retour à la normale.
> 
> Désolé pour le bruit !
> 
> 
> -- 
> 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] 1ere mondiale (enfin je crois) : le réseau de transport électrique français est routable

[David Marchal]

Bravo pour le boulot, François ! C’est parfois une plaie de dénouer les lignes, 
même avec les données de RTE.

Cordialement.

Le 7 janv. 2020 à 02:05, François Lacombe 
mailto:fl.infosrese...@gmail.com>> a écrit :

Salut à tous

Mon 1er mail de 2020 ici, donc bonne année à tous !
Que vos projets respectifs se concrétisent et surtout que vous y trouviez une 
satisfaction sans cesse renouvelée

Pour bien commencer, j'attire votre attention sur le changeset suivant :
https://www.openstreetmap.org/changeset/79224080

Il marque une étape importante dans la description du réseau de transport 
électrique, débutée dès 2008 je crois
L'ensemble des tensions 400kV et 225kV sont désormais routables en France, via 
l'emploi de + de 1500 relations cousues-main comme celles-ci
https://www.openstreetmap.org/relation/6194774
Elles représentent une continuité métallique avec plusieurs extrémités parfois. 
C'est expliqué ici :
https://wiki.openstreetmap.org/wiki/Power_networks/France#Circuits_et_routage_sur_le_r.C3.A9seau
Il ne me semble pas que pareil niveau ait été atteint ailleurs dans le monde.
http://overpass-turbo.eu/s/yUw

Le projet a été assorti de la description des postes extrémités, jusqu'aux 
arbres et places de parking
https://twitter.com/InfosReseaux/status/1210984860292206599?s=20

La complétude va permettre d'extraire une dizaine de jeux de données 
thématiques, dont la plupart n'a pas d'équivalent en données ouvertes, dans les 
prochaines semaines et de communiquer sur leur disponibilité.
On pourra parler :
- De la centaine de personnes ayant contribué de ~2008 jusqu'à maintenant
- Des milliers de km et de photos fait sur le terrain
- Des dizaines de milliers de km de lignes tracées sur vues aériennes (avant la 
dispo de l'opendata RTE)
- Des 1200 transformateurs de puissance traqués et positionnés
- Des dizaines d'hectares de pelouse tracées dans les postes (peut directement 
servir à la planification de l'emploi de moutons chez RTE pour limiter l'usage 
de produits phytosanitaires)
- Des milliers de km de jeux de barres, portiques, murs, voirie routière tracés 
dans les mêmes postes
- Des centaines d'arbres positionnés (il me semble)

+ probablement d'autres stats

Bref, c'est vraiment super
A bientôt !

François
___
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] adresse mail rejetée

[Philippe Verdy]

Mon analyse est limitée, mais comme j'ai eu une désinscription automatique
sans même être prévenu, pour que la liste soit contente je me suis
réinscrit aussi avec mon adresse Gmail.
J'ai toujours mon adresse wanadoo.fr inscrite, mais je n'utilise pas les
serveurs d'Orange pour les envois, juste pour la réception (l'adresse
wanadoo.fr est toujours valide et redirigée automatiquement vers Gmail).
Pour les nouveaux messages à la liste, j'envoie maintenant avec mon adresse
Gmail (je pourrais encore utiliser l'adresse Wanadoo au cas où quelqu'un
reprendrait un ancien fil ou mon adresse qui fonctionne toujours, mais que
je ne reçois pas, bien qu'elle est toujours inscrite à la liste, je reçois
malgré tout la copie à ma seconde adresse inscrite Gmail).
Parfois il arrive que les serveurs Orange fassent du "bounce", puis malgré
tout me transmet finalement le message (avec retard) mais alors les
serveurs d'Orange m'envoie le message de bounce du message de la liste
postée à mon adresse mail en lui ajoutant des entêtes dans le contenu
indiquant qu'Orange n'a pu transmettre le message original; je reçoi alors
le message modifié par Orange.
Cela arrive généralement quand celui qui a posté sur la liste son message a
utilisé une adresse non authentifiée (selon Orange) et qu'il a procédé à un
analyse anti-spam. Je note alors que le bounce envoyé par Orange à la liste
ne va pas sur la liste, mais m'est retourné en copie à mon adresse Gmail.
Je ne perds donc rien même si cela veut dire parfois des corps de message
modifiés par les serveurs d'Orange avec la notification d'échec de
livraison par Orange, mais le mail original venant de la liste inclus en
pièce jointe (parfois filtré s'il y a des images ou fichiers joints que je
ne vois pas). Je reçoi parfois ce message modifié par Orange en plus du
message que je reçois directement de la liste vers ma boite Gmail...

Bref, pour régler le problème j'ai simplement inscrit à la liste ma seconde
adresse @gmail.com en plus de celle (historique et valide depuis environ 30
ans) de @wanadoo.fr (j'ai eu des adresses aussi sur CompuServe et encore
d'autres avant sur des domaines qui n'existent plus). J'ai d'autres
adresses mail redirigées vers Gmail (dont un certain nombre de mes anciens
FAI: plusieurs d'Orange, de SFR, de Bouygues, de Free, et d'autres à usage
privé chez Yahoo, Hotmail/Live, tout va automatiquement vers Gmail ensuite).

Au final, il semble que seules les adresses Gmail et Yahoo fonctionnent
correctement et tout le temps avec les listes OSM. Tous les autres domaines
(Orange, Sosh, SFR, B, BouygTel, Free, et divers) ont des bounces de
temps en temps et ne suivent pas toujours les dernières préconisations pour
DMARC ou SPF ou SMTPS ou le DNS authentique et les certificats de domaine
(Orange en particulier oublie régulièrement d'inscrire des adresses IP de
ses serveurs SMTP dans le reverse DNS et cela peut durer des mois avant
qu'ils corrigent et créent et installent de nouveaux certificats à jour).

Le mar. 7 janv. 2020 à 16:53, marc marc  a
écrit :

> Bonjour,
>
> J'ai discuté avec TomH ce midi. Le soucis semble être double :
>
> - certains email sont protégé par spf et/ou dmarc,
> une technologique qui permet de préciser qui a le droit d'envoyer
> un email avec tel domaine ou tel serveur/ip.
> les listes de diffusion cassent cette protection (pour le destinataire,
> l'email n’apparaît plus comme venant de l'expéditeur d'origine mais
> comme venant d'un serveur sans rapport avec le domaine initial).
> Certains domaines de destination sont stricts sur ce critère,
> ce qui provoque un bounce et une fois atteint x bounce, le serveur de
> liste désinscrit ce destinataire.
> une modification a été faite à ce sujet pour modifier ces emails et
> mettre talk-fr comme expéditeur à la place (cfr mon email de 16h05
> comme exemple).
> cependant mon email suivant n'a pas été masqué, donc p'tre qu'il
> reste un problème.
>
> - certains domaines de destination ne semble pas aimer les emails
> redirigé. en effet ils reçoivent par exemple un email @wanadoo.fr
> avec l'ip d'un serveur qui n'est pas celui de wanadoo mais gmail.
> ils peuvent considérer cela comme de l'usurpation classique des spam.
> dans les logs, le serveur free.fr répond par exemple "550 spam detected"
> Pour résoudre cela, soit il faut demander à free.fr d'être moins strict
> (quasi aucune chance d'aboutir) soit les utilisateurs inscrits via un
> domaine mais qui transmettent cet email à un autre hébergeur devrait
> cesser ce le faire et s'inscrire directement avec cet autre hébergeur.
> les différents cas trouvé par TomH pour talk-fr concerne tous Philippe
> Verdy mais il n'a pas faire une analyse complète, donc si d'autres sont
> dans le cas, n'hésitez pas à signaler/migrer :)
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing 

Re: [Talk-de] OSM auf den Chemnitzer Linux-Tagen (14.3.-15.3.)

[Christopher Lorenz via Talk-de]

Hallo,
Die Idee mit dem stream hat ich auch schon. Aber Samstag wird ja bislang soweit 
ich weiß nur Eröffnung und Abschluss aufgezeichnet bzw. Gestreamt.

Christopher 

Am 7. Januar 2020 16:35:52 MEZ schrieb Falk Zscheile :
>Am Mo., 6. Jan. 2020 um 20:43 Uhr schrieb Michael Kugelmann via
>Talk-de :
>>
>> Am 06.01.2020 um 15:27 schrieb André Riedel:
>> > https://chemnitzer.linux-tage.de/2020/de
>> schade: findet am 14. und 15.3. 2019 statt und kollidiert somit leider
>> mit dem OSM-Samstag der FOSSGIS-Konferenz in Freiburg:
>> https://fossgis-konferenz.de/2020/
>> https://wiki.openstreetmap.org/wiki/FOSSGIS_2020 bzw.
>> https://wiki.openstreetmap.org/wiki/FOSSGIS_2020/OSM-Samstag
>
>Dann kann es am OSM-Stand auf den Chemnitzer Linuxtagen eine
>Liveübertragung aus Freiburg geben :-)
>
>Viele Grüße
>
>Falk
>
>___
>Talk-de mailing list
>Talk-de@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-de
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] mapping outside Europe

[Martin Constantino–Bodin]

apart from the issue "international objects receive a tag 'name' with 
an English value", there are other ways in which you see how we're 
letting USA-UK patronize the rest.


the latest example in my experience would be the 'sac_scale' tagging.  
it comes from the SAC-CAS classification, of the Schweizer 
Alpen-Club/Club Alpino Svizzero/Club Alpin Suisse/Club Alpin Svizzer, 
yet OSM held the discussion in English, and it not only chose 
`sac_scale` for the tag name, it also decided not to use the Swiss 
codes T1..T6 (language independent), but the English version of the 
human readable explanation for the codes: T1 
(hiking/escursione/randonnée/Wandern) .. T6 (difficult alpine 
hiking/escursione alpina difficile/randonnée alpine 
difficile/schwieriges Alpinwandern).


a more important issue (I would call it "mapping outside Europe", 
hence the subject) is for me each and every (photo)graphic explanation 
of the tagging values.  take `highway` 
(https://wiki.openstreetmap.org/wiki/Key:highway).  text are fine, 
really, but the associated pictures seem all taken in Europe, or North 
America, they have more chances to confuse the mapper based in Africa 
or South America, than helping them.


in Panama many roads are classified as 'camino de verano', they look 
like highway:track, but are really highway:unclassified with an extra 
indication for the months where they are expected to be passable.  
maybe can be solved in the wiki by changing the link to the picture 
into a link to several pictures, but I'm afraid that we need to 
address this in the standard renderer as well: users also expect some 
of the information to be reflected in the rendering, explaining why so 
many mappers still use highway:track despite one repeating "don't map 
for the renderer".


in Morocco (and I guess elsewhere too) we have small towns with 
undeveloped areas, crossed by paths with residential function, or 
large cities with extremely narrow alleys, again with residential 
function.  these have been solved by different mappers in different 
ways, leading to very inconsistent mapping, in particular where there 
isn't a local, assertive, mappers' community.  (Morocco and Panama are 
two such cases, Colombia is much better in this aspect.)


Wow. That’s quite impressive examples. I fully agree that this 
Europe-centrism might lead to issues in the future. I remembered being 
quite confused when I first read the documentation for crossing ways, as 
they are all following UK’s naming system (which I’ve never heard 
before). They are well-documented, so I guess that it’s fine. But I 
understand what you mean: the “name” tag issue may not be the most 
relevant in this family of issues.


This might indicate that the people discussing in this mailing list are 
from a very specific background, possibly caused by the language of the 
mailing list itself.


At the same time, I have to admit that I don’t feel like there are that 
much pictures on the documentation. I was for instance surprised that 
there was no picture for the “minimap” tag in the wiki (I fixed this in 
the meantime ☺). So it might be something that we can easily improve 
step by step ☺


I’m not sure what to conclude here. I guess that being conscious of the 
Europe-centrism issue during discussions might help? Or that we may need 
to look for volunteers to complete the OSM wiki with additional pictures 
from non-Europe/North America? I will look at the pictures I took back 
to been I lived in Chile and Brazil… but as I wasn’t into OSM then, I 
won’t have much useful ​


Regards,
Martin.


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

Re: [OSM-talk-fr] Comment libeller une fontaine d'eau en pierre (qui n'est pas un monument) ?

[European Water Project]

Bonjour Chris,

Nous suggerons dans nos instructions de mettre "amenity=fountain et
drinking_water=yes" quand une fontaine qui mérite ce nom est indiquée
potable et de mettre  "amenity=fountain et drinking_water=no" quand c'est
indiquée potable. Et nous dirons la meme chose pour tous les pays.

Et pour les fontaines modernes comme dans les aeroports, gares, ecoles,
etc, nous suggerons de mettre "amenity=drinking_water".

Bien cordialement,

Stuart



On Tue, 7 Jan 2020 at 17:05, Christian Quest 
wrote:

> Le 07/01/2020 à 15:45, European Water Project a écrit :
> > Malheureusement en France, la grande majorité de fontaines en pierre
> > avec de l'eau 100% potable sont libellée "non potable" par peur du
> > procès des maires (et ils ont raisons, tant que la legislation ne
> > change). Dans ce cas, faut-il mettre "amenity=fountain et
> > drinking_water=no".  Et si un jour la legislation change pour ces
> > fontaines, on mettra que "amenity=drinking_water" ?
>
>
> On voit aussi assez souvent quelque chose de plus honnête: "eau non
> contrôlée"
>
> amenity=drinking_water : ça indique un point d'eau potable
>
> amenity=fountain : une fontaine (le monument ou l'objet avec une
> vocation décorative et pas juste utilitaire)
>
> - si l'eau est potable: drinking_water=yes
>
> - si elle ne l'est pas: drinking_water=no
>
> - si elle est "non contrôle": drinking_water=conditional
>
> - si on ne sait pas on ne met rien
>
> Je ne connaissais pas drinking_water:legal
>
> Le wiki donne comme toujours bien plus de détails et décrit aussi
> amenity=water_point où l'on peut puiser de grandes quantité d'eau
> (potable ou non)
>
>
> --
> 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-be] Tagging proposal for cycling highways (Fietssnelwegen)

[jul gijbels]

Hey everyone,


a lot of the cycling highways are listed :

https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Cycle_Routes#Vlaanderen


including the mapt relation and a status


jul2


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

[OSM-talk-fr] Sur utilisation non nécessaire des espaces de nom — Re: Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[Yves P.]

—
Yves Pratter




> Le 7 janv. 2020 à 16:19, marc marc  a écrit :
> 
> Pour ma part, je me posais la question de ce que je considère comme
> une surutilisation non nécessaire des espaces de nom (l’enchaînement
> de clef: pour préciser une clef)
> je vais faire une comparaison avec les routes :
> en lisant une référence sur le panneau d'une route, cette référence
> se retranscrit dans la clef ref=numéro et ceci indépendamment de
> l'opérateur ou du pays.
> on n'utilise pas non plus d'espace de nom du genre ref:FR:auteur
> pour préciser qui serrait l'auteur de la ref.
> on n'utilise pas non plus de mot dans la clef pour donner le sens de
> cette référence ou le terme légal que celui-ci aurait dans la loi.


> Au final l'utilisateur qui lit une ref quelque part, ne peux pas
> l'ajouter dans osm sans devoir chercher dans le wiki quel est la règle
> particulière qui régit cet objet dans ce pays.
ce qui est aussi pénible, c’est que les rendus n’affichent pas les ref:xyz et 
que les modèles de saisie (preset) non que le champ de saisie ref.

> cela nuit à mon avis grandement à l'encodage simple et même à l’utilisation

> (essayez donc de connaître le nombre de power=substation
> au niveau mondial qui ont une ref, vous devez écrire une règle qui dit
> que cela peux être ref ou ref:* chose que de nombreux outil tel que
> tainfo ou overpass ne permettent pas ou pas facilement)
si on ne connait pas la ref:* à mettre, on peut mettre ref tout simplement.

> A l'inverse, dans le domaine énergétique (et des transports), au fil
> du temps, on utilise des espaces de nom pour la clef ref en France,
> sans que je perçoive ni le besoin ni même l’intérêt.
Les intérêts sont :
de lier l’objet OSM à un objet dans une base de donnée externe.
pour un objet qui a plusieurs références, de les différencier.
pour une machine (voir un humain), de savoir à quoi ça correspond. Référence de 
l’opérateur, de la commune… ?

Exemple d’un poste de transformation électrique :
On trouve souvent une référence GDO et une référence concernant l’éclairage 
public.
En pratique cette dernière se trouve sur un disjoncteur, mais comme on ne fait 
pas encore de micro mapping à ce niveau, il faudrait mettre les deux valeur 
dans reference=

Exemple d’une bouée en mer ou d’un phare : 
ref:nga la référence dans le livre des feux américain
ref:admiralty : la référence internationale (celle du livre des feux anglais)
une référence nationale (ref:ef pour l’Italie, ref:aladin pour la France, 
ref:uscg pour les USA, …)

—
Yves


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

Re: [OSM-talk-fr] Comment libeller une fontaine d'eau en pierre (qui n'est pas un monument) ?

[Christian Quest]

Le 07/01/2020 à 15:45, European Water Project a écrit :
Malheureusement en France, la grande majorité de fontaines en pierre 
avec de l'eau 100% potable sont libellée "non potable" par peur du 
procès des maires (et ils ont raisons, tant que la legislation ne 
change). Dans ce cas, faut-il mettre "amenity=fountain et 
drinking_water=no".  Et si un jour la legislation change pour ces 
fontaines, on mettra que "amenity=drinking_water" ?



On voit aussi assez souvent quelque chose de plus honnête: "eau non 
contrôlée"


amenity=drinking_water : ça indique un point d'eau potable

amenity=fountain : une fontaine (le monument ou l'objet avec une 
vocation décorative et pas juste utilitaire)


- si l'eau est potable: drinking_water=yes

- si elle ne l'est pas: drinking_water=no

- si elle est "non contrôle": drinking_water=conditional

- si on ne sait pas on ne met rien

Je ne connaissais pas drinking_water:legal

Le wiki donne comme toujours bien plus de détails et décrit aussi 
amenity=water_point où l'on peut puiser de grandes quantité d'eau 
(potable ou non)



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Comment libeller une fontaine d'eau en pierre (qui n'est pas un monument) ?

[European Water Project]

Bonjour Philippe,



Et pourtant, la politique d'autre côté de nos frontières est très
différente. Plus que 70.000 fontaines potables en Italie. (Nous préparons
un "fountain hunt" en avril à Rome avec My-D.org et Wikimedia Suisse). Et à
2 kilomètres de notre maison, de l'autre côté de la frontière en Suisse
toutes les fontaines sont potables.



Avant 1970, quand les bouteilles en PET sont introduites nos fontaines
étaient utilisées quotidiennement ...  Peut-être la réponse est plus
nuancée et les industriels ont eu leur mot à dire dans l'écriture de cette
histoire.



Bien à toi,



Stuart

On Tue, 7 Jan 2020 at 16:40, Philippe Verdy  wrote:

> Hormi le cas des simples robinets à bouton poussoir du mobilier urbain,
> les fontaines avec un bac de pierre peuvent être qualifiés de "monuments",
> témoins d'un passé architectural et de l'activité du village.
> Elles peuvent être potables ou non mais ce sont des "fontaines",
> amenity=fountain et sont encore utilisées pour l'arrosage même si ce n'est
> plus pour boire, car non testé (parfois aussi des sources
> "waterway=spring"). Ces fontaines traditionnelles et préservées par les
> communes, sont marquées de panneaux "eau non potable" en cas de besoin (en
> fait bien des fontaines sont potables, mais les communes ne veulent pas
> prendre de risque si c'est une source naturelle, puisque l'eau n'est pas
> traitée, donc pas testée en continu, à moins que des travaux aient été
> faits pour les raccorder au réseau d'eau potable, et dans ce cas il y a un
> robinet car on ne gache pas les eaux traitées par une écoulement continu).
> Bref fountain=yes, drinking_water=no est bien souvent le signe d'un
> waterway=spring (ou d'une résurgence naturelle, ou d'une rigole
> d'infiltration, qui pourrait aussi être le déversoir d'un étang plus haut
> sur une colline, qui est susceptible d'être pollué par les eaux de
> ruissellements et le drainage de fossés le long de parcelles agricoles
> traitées, de routes ou de pollutions alentour).
> En France il n'est plus possible depuis longtemps de boire directement
> l'eau des fleuves et rivières sans traitement par le réseau d'eau potable
> (on n'est pas au milieu d'une île indonésienne où c'est encore possible, ce
> n'est déjà plus possible en Guyane ou en Nouvelle-Calédonie à cause de
> l'orpaillage et des mines, la pollution catastrophique que cela a entrainé
> dans les cours d'eau et la faune aquatique).
> La présence d'un robinet ne garantie pas non plus la potabilité (les
> déversoirs peuvent servir à alimenter les stations de traitement des eaux
> et il faut préserver les nappes d'alimentation et ne pas les laisser se
> vider en continu sans contrôle; il ne doit plus rester beaucoup de
> fontaines sans robinet, sauf si ce sont des sources de ruisseaux ou si
> c'est de l'eau qui s'écoule d'un petit bief de dérivation à partir d'un
> débordement, dans ce cas la fontaine est intermittente et on peut avoir
> intermittent=yes en plus sur cette fontaine, comme aussi toute autre source
> de ruisseau intermittent)
>
> Le mar. 7 janv. 2020 à 16:22, European Water Project <
> europeanwaterproj...@gmail.com> a écrit :
>
>> Merci Marc
>>
>> Pour les fontaines qui sont indiquées "non potable", nous ne pouvons
>> qu'inciter les personnes de ne pas libeller la fontaine comme autre chose
>> que "amenty=fountain et drinking_water=no". Nous ne pouvons pas assurer de
>> la qualité de l'eau sans que les testes (qui ne sont pas couteux) soit
>> faites par les autoritées compétentes et je ne prendrai pas cette
>> responsabilité.
>>
>> Et dans ce cas,  il y a une incoherence entre une belle fontaine en
>> pierre dans un village français qui sera juste "amenity=drinking_water" is
>> l'eau est potable, et "amenity=fountain" et "drinking_water=no" si la
>> fontaine n'est pas potable.
>>
>> bien cordialement,
>>
>> Stuart
>>
>> On Tue, 7 Jan 2020 at 16:05, marc marc via Talk-fr <
>> talk-fr@openstreetmap.org> wrote:
>>
>>> Bonjour,
>>>
>>> il y a 2 points différents dans ta question
>>>
>>> 1) à quoi ressemble l'objet ?
>>> la différence entre amenity=drinking_water <> amenity=fountain
>>> concerne l'apparence.
>>> un simple robinet d’où coule de l'eau avec une plaque d'égout en
>>> dessous, ce n'est pas une fontaine.
>>> un objet artistique, avec parfois plusieurs jets ou sculpté a des chance
>>> d'être une fontaine.
>>> évidement le problème est entre les 2 (ex un objet en pierre sculpté
>>> avec un simple jet d'eau). mais je suis d'accord avec Stefan : à priori
>>> quand il y a un doute, c'est un amenity=drinking_water
>>> il ne serrait d'ailleurs pas trop grave de mettre amenity=drinking_water
>>> sur une fontaine, osm se fait de manière incrémentielle, une fois la
>>> localisation précise connue, et qui plus est grâce aux photos que vous
>>> voulez récolter, il serrait facile d'améliorer la description de l'objet
>>> dans osm si nécessaire
>>>
>>> 2) potable ou non potable ? légalement ou en pratique ?
>>> tant un point d'eau qu'une fontaine 

Re: [OSM-talk] [Tagging] Tagging the local language

[Mario Frasca]

On 07/01/2020 06:53, Martin Constantino–Bodin wrote:
Maybe we can sometimes factorise? Like “América del Sur / do Sul” for 
South America


fortunate case: it's América in both languages (Catalan has Amèrica).

you can possibly even use América Meridional and cover both in one shot.


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

[OSM-talk] mapping outside Europe

[Mario Frasca]

On 07/01/2020 05:38, Martin Constantino–Bodin wrote:
I really don’t think that we want to unconsciously impose such culture 
in our community.


Hi Martin, and thank you for considering the issue constructively.

apart from the issue "international objects receive a tag 'name' with an 
English value", there are other ways in which you see how we're letting 
USA-UK patronize the rest.


the latest example in my experience would be the 'sac_scale' tagging.  
it comes from the SAC-CAS classification, of the Schweizer 
Alpen-Club/Club Alpino Svizzero/Club Alpin Suisse/Club Alpin Svizzer, 
yet OSM held the discussion in English, and it not only chose 
`sac_scale` for the tag name, it also decided not to use the Swiss codes 
T1..T6 (language independent), but the English version of the human 
readable explanation for the codes: T1 
(hiking/escursione/randonnée/Wandern) .. T6 (difficult alpine 
hiking/escursione alpina difficile/randonnée alpine 
difficile/schwieriges Alpinwandern).


a more important issue (I would call it "mapping outside Europe", hence 
the subject) is for me each and every (photo)graphic explanation of the 
tagging values.  take `highway` 
(https://wiki.openstreetmap.org/wiki/Key:highway).  text are fine, 
really, but the associated pictures seem all taken in Europe, or North 
America, they have more chances to confuse the mapper based in Africa or 
South America, than helping them.


in Panama many roads are classified as 'camino de verano', they look 
like highway:track, but are really highway:unclassified with an extra 
indication for the months where they are expected to be passable.  maybe 
can be solved in the wiki by changing the link to the picture into a 
link to several pictures, but I'm afraid that we need to address this in 
the standard renderer as well: users also expect some of the information 
to be reflected in the rendering, explaining why so many mappers still 
use highway:track despite one repeating "don't map for the renderer".


in Morocco (and I guess elsewhere too) we have small towns with 
undeveloped areas, crossed by paths with residential function, or large 
cities with extremely narrow alleys, again with residential function.  
these have been solved by different mappers in different ways, leading 
to very inconsistent mapping, in particular where there isn't a local, 
assertive, mappers' community.  (Morocco and Panama are two such cases, 
Colombia is much better in this aspect.)


best to all,

MF


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

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[Philippe Verdy]

pour les routes (sur la voie publique) on n'a pas besoin de clé car il n'y
a à priori qu'un opérateur public attitré localement (indiqué par la/les
premières lettres).
Cependant des références multiples existent pour différents opérateurs (pas
tous attitrés localement, et pas tous pour le domaine public uniquement),
et on ne peut pas faire autrement que de mettre une clé spécifique pour
chacun (exemples : lignes de transport, réseaux cyclables, opérateurs
sportifs, référence de tourisme et randonnée...).
Pour les équipements électriques, tous ne sont pas sur le réseau public
général et GDO n'est plus le seul opérateur non plus. Si on veut distinguer
les réseaux, pas moyen non plus de se passer de clé, car il n'y a pas de
standard hors du réseau public de transport; de plus les opérateurs publics
ne sont plus uniques non plus (selon la collectivité qui commande les
branches du réseau et peut avoir des liaisons spécifiques venant d'autre
territoires hors de la collectivité ou du gros client final qui l'a
commandé).
Il y a aussi plein de réseaux de distribution ou d'alimentation avec eux
aussi leurs équipements (transformateurs et convertisseurs
continu/alternatif, isolateurs et coupe-circuits, postes de contrôle,
jonctions entre réseau enterré et réseau aérien, etc., petits batiments ou
armoires de rue ou cabinets sous-terrain sous une plaque pour la
distribution, pas tous non plus sur le domaine public mais parfois enclavés
dans un terrain privé, comme le sont aussi pas mal de poteaux et pylones au
milieu des champs et forêts et pas toujours avec un chemin public pour y
mener, parfois juste un chemin agricole privé avec un droit de passage pour
les techniciens)

Le mar. 7 janv. 2020 à 16:20, marc marc  a
écrit :

> Bonjour,
>
> Le 07.01.20 à 16:01, Quentin Salles a écrit :
> > Pouvez-vous me confirmer que l'usage de la clé "ref:FR:gdo" est bien
> actif ?
>
> Nous n'avions pas terminé la discussion sur la migration.
> Je te conseille d'utiliser l'ancienne clef en attendant, puisque
> c'est elle qui est la façon de faire actuellement.
>
> Pour ma part, je me posais la question de ce que je considère comme
> une surutilisation non nécessaire des espaces de nom (l’enchaînement
> de clef: pour préciser une clef)
> je vais faire une comparaison avec les routes :
> en lisant une référence sur le panneau d'une route, cette référence
> se retranscrit dans la clef ref=numéro et ceci indépendamment de
> l'opérateur ou du pays.
> on n'utilise pas non plus d'espace de nom du genre ref:FR:auteur
> pour préciser qui serrait l'auteur de la ref.
> on n'utilise pas non plus de mot dans la clef pour donner le sens de
> cette référence ou le terme légal que celui-ci aurait dans la loi.
>
> A l'inverse, dans le domaine énergétique (et des transports), au fil
> du temps, on utilise des espaces de nom pour la clef ref en France,
> sans que je perçoive ni le besoin ni même l'intérêt.
>
> Au final l'utilisateur qui lit une ref quelque part, ne peux pas
> l'ajouter dans osm sans devoir chercher dans le wiki quel est la règle
> particulière qui régit cet objet dans ce pays.
> cela nuit à mon avis grandement à l'encodage simple et même à
> l'utilisation (essayez donc de connaître le nombre de power=substation
> au niveau mondial qui ont une ref, vous devez écrire une règle qui dit
> que cela peux être ref ou ref:* chose que de nombreux outil tel que
> tainfo ou overpass ne permettent pas ou pas facilement)
>
> > Est-il possible de remonter l'information
> > via l'Open data. Si oui, est-il permis d'ajouter ces informations non
> > visibles sur le terrain ?
>
> bien sur, osmose ne propose rien sur le sujet ?
> https://osmose.openstreetmap.fr/fr/map/
>
> Cordialement,
> Marc
> ___
> 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] adresse mail rejetée

[marc marc]

Bonjour,

J'ai discuté avec TomH ce midi. Le soucis semble être double :

- certains email sont protégé par spf et/ou dmarc,
une technologique qui permet de préciser qui a le droit d'envoyer
un email avec tel domaine ou tel serveur/ip.
les listes de diffusion cassent cette protection (pour le destinataire,
l'email n’apparaît plus comme venant de l'expéditeur d'origine mais
comme venant d'un serveur sans rapport avec le domaine initial).
Certains domaines de destination sont stricts sur ce critère,
ce qui provoque un bounce et une fois atteint x bounce, le serveur de
liste désinscrit ce destinataire.
une modification a été faite à ce sujet pour modifier ces emails et
mettre talk-fr comme expéditeur à la place (cfr mon email de 16h05
comme exemple).
cependant mon email suivant n'a pas été masqué, donc p'tre qu'il
reste un problème.

- certains domaines de destination ne semble pas aimer les emails
redirigé. en effet ils reçoivent par exemple un email @wanadoo.fr
avec l'ip d'un serveur qui n'est pas celui de wanadoo mais gmail.
ils peuvent considérer cela comme de l'usurpation classique des spam.
dans les logs, le serveur free.fr répond par exemple "550 spam detected"
Pour résoudre cela, soit il faut demander à free.fr d'être moins strict
(quasi aucune chance d'aboutir) soit les utilisateurs inscrits via un
domaine mais qui transmettent cet email à un autre hébergeur devrait
cesser ce le faire et s'inscrire directement avec cet autre hébergeur.
les différents cas trouvé par TomH pour talk-fr concerne tous Philippe
Verdy mais il n'a pas faire une analyse complète, donc si d'autres sont
dans le cas, n'hésitez pas à signaler/migrer :)

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

Re: [OSM-talk-fr] Comment libeller une fontaine d'eau en pierre (qui n'est pas un monument) ?

[European Water Project]

Merci Marc

Je suis d'accord que ça doit etre libellée comme ça, donc ça me plait !

A bientôt,

Stuart



On Tue, 7 Jan 2020 at 16:35, marc marc  wrote:

> pour ceux craintif à propos de l'aspect légal,
> c'est justement l'intérêt du tag drinking_water:legal
> il fait la différence entre "tout le monde la boit" et "qlq a
> fait l'analyse et/ou a posé un panneau qui le dit"
>
> il y a une erreur dans ton raisonnement ci-dessous :
> une belle fontaine en pierre et potable est amenity=fountain
> et drinking_water=yes
>
> Le 07.01.20 à 16:20, European Water Project a écrit :
> > Merci Marc
> >
> > Pour les fontaines qui sont indiquées "non potable", nous ne pouvons
> > qu'inciter les personnes de ne pas libeller la fontaine comme autre
> > chose que "amenty=fountain et drinking_water=no". Nous ne pouvons pas
> > assurer de la qualité de l'eau sans que les testes (qui ne sont pas
> > couteux) soit faites par les autoritées compétentes et je ne prendrai
> > pas cette responsabilité.
> >
> > Et dans ce cas,  il y a une incoherence entre une belle fontaine en
> > pierre dans un village français qui sera juste "amenity=drinking_water"
> > is l'eau est potable, et "amenity=fountain" et "drinking_water=no" si la
> > fontaine n'est pas potable.
> >
> > bien cordialement,
> >
> > Stuart
> >
> > On Tue, 7 Jan 2020 at 16:05, marc marc via Talk-fr
> > mailto:talk-fr@openstreetmap.org>> wrote:
> >
> > Bonjour,
> >
> > il y a 2 points différents dans ta question
> >
> > 1) à quoi ressemble l'objet ?
> > la différence entre amenity=drinking_water <> amenity=fountain
> > concerne l'apparence.
> > un simple robinet d’où coule de l'eau avec une plaque d'égout en
> > dessous, ce n'est pas une fontaine.
> > un objet artistique, avec parfois plusieurs jets ou sculpté a des
> chance
> > d'être une fontaine.
> > évidement le problème est entre les 2 (ex un objet en pierre sculpté
> > avec un simple jet d'eau). mais je suis d'accord avec Stefan : à
> priori
> > quand il y a un doute, c'est un amenity=drinking_water
> > il ne serrait d'ailleurs pas trop grave de mettre
> amenity=drinking_water
> > sur une fontaine, osm se fait de manière incrémentielle, une fois la
> > localisation précise connue, et qui plus est grâce aux photos que
> vous
> > voulez récolter, il serrait facile d'améliorer la description de
> l'objet
> > dans osm si nécessaire
> >
> > 2) potable ou non potable ? légalement ou en pratique ?
> > tant un point d'eau qu'une fontaine peux fournir de l'eau potable
> > ou non ou potable sans garantie légale
> > Pour ma part, je m'en tiens à la page wiki
> > https://wiki.openstreetmap.org/wiki/Key%3Adrinking_water
> > s'il y a un panneau potable ou si c'est manifestement fait pour se
> > désaltérer (cas du mobilier urbain avec un robinet ou bouton
> poussoir)
> > amenity=drinking_water ou drinking_water:legal=yes sur une fontaine
> > s'il y a un panneau non potable drinking_water:legal=no
> > s'il me semble raisonnable de boire l'eau drinking_water=yes
> > s'il me semble déraisonnable de boire l'eau drinking_water=no
> >
> > Cordialement,
> > Marc
> >
> > Le 07.01.20 à 15:45, European Water Project a écrit :
> > > Bonjour,
> > >
> > > Nous avons les instructions maintenant en 6 langues pour comment
> > ajouter
> > > une fontaine en OpenStreetMap et une photo d'une fontaine en
> Wikimedia
> > > Commons. Nous avons eu beaucoup d'aide pour completer cette tache
> > d'OSM
> > > Suisse et d'OSM Espagne.
> > >
> > >
> >
> https://meta.wikimedia.org/wiki/Wikimedia_CH/Project/European_Water_Project/fr
>
> > >
> > > Stefan Keller d'OSM Suisse nous conseil de mettre comme tag pour la
> > > grande majorité de fontaines que  "amenity=drinking_water" et de
> > ne pas
> > > mettre 2) "amenity=fountain et drinking_water=yes".  Vous etes
> plutôt
> > > d'accord ? Malheureusement en France, la grande majorité de
> > fontaines en
> > > pierre avec de l'eau 100% potable sont libellée "non potable" par
> peur
> > > du procès des maires (et ils ont raisons, tant que la legislation
> ne
> > > change). Dans ce cas, faut-il mettre "amenity=fountain et
> > > drinking_water=no".  Et si un jour la legislation change pour ces
> > > fontaines, on mettra que "amenity=drinking_water" ?
> > >
> > > Bien cordialement,
> > >
> > > Stuart
> > >
> > >
> > >
> > > On Fri, 27 Dec 2019 at 14:13, European Water Project
> > >  > 
> >  > >>
> > > wrote:
> > >
> > > Bonjour,
> > >
> > >
> > >
> > > Je serai reconnaissant si vous pouvez nous donner vos
> commentaires
> > > sur les instructions en français de comment ajouter une
> fontaine
> > > 

Re: [OSM-talk-fr] Comment libeller une fontaine d'eau en pierre (qui n'est pas un monument) ?

[Philippe Verdy]

Hormi le cas des simples robinets à bouton poussoir du mobilier urbain, les
fontaines avec un bac de pierre peuvent être qualifiés de "monuments",
témoins d'un passé architectural et de l'activité du village.
Elles peuvent être potables ou non mais ce sont des "fontaines",
amenity=fountain et sont encore utilisées pour l'arrosage même si ce n'est
plus pour boire, car non testé (parfois aussi des sources
"waterway=spring"). Ces fontaines traditionnelles et préservées par les
communes, sont marquées de panneaux "eau non potable" en cas de besoin (en
fait bien des fontaines sont potables, mais les communes ne veulent pas
prendre de risque si c'est une source naturelle, puisque l'eau n'est pas
traitée, donc pas testée en continu, à moins que des travaux aient été
faits pour les raccorder au réseau d'eau potable, et dans ce cas il y a un
robinet car on ne gache pas les eaux traitées par une écoulement continu).
Bref fountain=yes, drinking_water=no est bien souvent le signe d'un
waterway=spring (ou d'une résurgence naturelle, ou d'une rigole
d'infiltration, qui pourrait aussi être le déversoir d'un étang plus haut
sur une colline, qui est susceptible d'être pollué par les eaux de
ruissellements et le drainage de fossés le long de parcelles agricoles
traitées, de routes ou de pollutions alentour).
En France il n'est plus possible depuis longtemps de boire directement
l'eau des fleuves et rivières sans traitement par le réseau d'eau potable
(on n'est pas au milieu d'une île indonésienne où c'est encore possible, ce
n'est déjà plus possible en Guyane ou en Nouvelle-Calédonie à cause de
l'orpaillage et des mines, la pollution catastrophique que cela a entrainé
dans les cours d'eau et la faune aquatique).
La présence d'un robinet ne garantie pas non plus la potabilité (les
déversoirs peuvent servir à alimenter les stations de traitement des eaux
et il faut préserver les nappes d'alimentation et ne pas les laisser se
vider en continu sans contrôle; il ne doit plus rester beaucoup de
fontaines sans robinet, sauf si ce sont des sources de ruisseaux ou si
c'est de l'eau qui s'écoule d'un petit bief de dérivation à partir d'un
débordement, dans ce cas la fontaine est intermittente et on peut avoir
intermittent=yes en plus sur cette fontaine, comme aussi toute autre source
de ruisseau intermittent)

Le mar. 7 janv. 2020 à 16:22, European Water Project <
europeanwaterproj...@gmail.com> a écrit :

> Merci Marc
>
> Pour les fontaines qui sont indiquées "non potable", nous ne pouvons
> qu'inciter les personnes de ne pas libeller la fontaine comme autre chose
> que "amenty=fountain et drinking_water=no". Nous ne pouvons pas assurer de
> la qualité de l'eau sans que les testes (qui ne sont pas couteux) soit
> faites par les autoritées compétentes et je ne prendrai pas cette
> responsabilité.
>
> Et dans ce cas,  il y a une incoherence entre une belle fontaine en pierre
> dans un village français qui sera juste "amenity=drinking_water" is l'eau
> est potable, et "amenity=fountain" et "drinking_water=no" si la fontaine
> n'est pas potable.
>
> bien cordialement,
>
> Stuart
>
> On Tue, 7 Jan 2020 at 16:05, marc marc via Talk-fr <
> talk-fr@openstreetmap.org> wrote:
>
>> Bonjour,
>>
>> il y a 2 points différents dans ta question
>>
>> 1) à quoi ressemble l'objet ?
>> la différence entre amenity=drinking_water <> amenity=fountain
>> concerne l'apparence.
>> un simple robinet d’où coule de l'eau avec une plaque d'égout en
>> dessous, ce n'est pas une fontaine.
>> un objet artistique, avec parfois plusieurs jets ou sculpté a des chance
>> d'être une fontaine.
>> évidement le problème est entre les 2 (ex un objet en pierre sculpté
>> avec un simple jet d'eau). mais je suis d'accord avec Stefan : à priori
>> quand il y a un doute, c'est un amenity=drinking_water
>> il ne serrait d'ailleurs pas trop grave de mettre amenity=drinking_water
>> sur une fontaine, osm se fait de manière incrémentielle, une fois la
>> localisation précise connue, et qui plus est grâce aux photos que vous
>> voulez récolter, il serrait facile d'améliorer la description de l'objet
>> dans osm si nécessaire
>>
>> 2) potable ou non potable ? légalement ou en pratique ?
>> tant un point d'eau qu'une fontaine peux fournir de l'eau potable
>> ou non ou potable sans garantie légale
>> Pour ma part, je m'en tiens à la page wiki
>> https://wiki.openstreetmap.org/wiki/Key%3Adrinking_water
>> s'il y a un panneau potable ou si c'est manifestement fait pour se
>> désaltérer (cas du mobilier urbain avec un robinet ou bouton poussoir)
>> amenity=drinking_water ou drinking_water:legal=yes sur une fontaine
>> s'il y a un panneau non potable drinking_water:legal=no
>> s'il me semble raisonnable de boire l'eau drinking_water=yes
>> s'il me semble déraisonnable de boire l'eau drinking_water=no
>>
>> Cordialement,
>> Marc
>>
>> Le 07.01.20 à 15:45, European Water Project a écrit :
>> > Bonjour,
>> >
>> > Nous avons les instructions maintenant en 6 langues pour comment ajouter
>> > 

Re: [Talk-de] OSM auf den Chemnitzer Linux-Tagen (14.3.-15.3.)

[Falk Zscheile]

Am Mo., 6. Jan. 2020 um 20:43 Uhr schrieb Michael Kugelmann via
Talk-de :
>
> Am 06.01.2020 um 15:27 schrieb André Riedel:
> > https://chemnitzer.linux-tage.de/2020/de
> schade: findet am 14. und 15.3. 2019 statt und kollidiert somit leider
> mit dem OSM-Samstag der FOSSGIS-Konferenz in Freiburg:
> https://fossgis-konferenz.de/2020/
> https://wiki.openstreetmap.org/wiki/FOSSGIS_2020 bzw.
> https://wiki.openstreetmap.org/wiki/FOSSGIS_2020/OSM-Samstag

Dann kann es am OSM-Stand auf den Chemnitzer Linuxtagen eine
Liveübertragung aus Freiburg geben :-)

Viele Grüße

Falk

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

Re: [OSM-talk-fr] Comment libeller une fontaine d'eau en pierre (qui n'est pas un monument) ?

[marc marc]

pour ceux craintif à propos de l'aspect légal,
c'est justement l'intérêt du tag drinking_water:legal
il fait la différence entre "tout le monde la boit" et "qlq a
fait l'analyse et/ou a posé un panneau qui le dit"

il y a une erreur dans ton raisonnement ci-dessous :
une belle fontaine en pierre et potable est amenity=fountain
et drinking_water=yes

Le 07.01.20 à 16:20, European Water Project a écrit :
> Merci Marc
> 
> Pour les fontaines qui sont indiquées "non potable", nous ne pouvons
> qu'inciter les personnes de ne pas libeller la fontaine comme autre
> chose que "amenty=fountain et drinking_water=no". Nous ne pouvons pas
> assurer de la qualité de l'eau sans que les testes (qui ne sont pas
> couteux) soit faites par les autoritées compétentes et je ne prendrai
> pas cette responsabilité. 
> 
> Et dans ce cas,  il y a une incoherence entre une belle fontaine en
> pierre dans un village français qui sera juste "amenity=drinking_water"
> is l'eau est potable, et "amenity=fountain" et "drinking_water=no" si la
> fontaine n'est pas potable. 
> 
> bien cordialement,
> 
> Stuart 
> 
> On Tue, 7 Jan 2020 at 16:05, marc marc via Talk-fr
> mailto:talk-fr@openstreetmap.org>> wrote:
> 
> Bonjour,
> 
> il y a 2 points différents dans ta question
> 
> 1) à quoi ressemble l'objet ?
> la différence entre amenity=drinking_water <> amenity=fountain
> concerne l'apparence.
> un simple robinet d’où coule de l'eau avec une plaque d'égout en
> dessous, ce n'est pas une fontaine.
> un objet artistique, avec parfois plusieurs jets ou sculpté a des chance
> d'être une fontaine.
> évidement le problème est entre les 2 (ex un objet en pierre sculpté
> avec un simple jet d'eau). mais je suis d'accord avec Stefan : à priori
> quand il y a un doute, c'est un amenity=drinking_water
> il ne serrait d'ailleurs pas trop grave de mettre amenity=drinking_water
> sur une fontaine, osm se fait de manière incrémentielle, une fois la
> localisation précise connue, et qui plus est grâce aux photos que vous
> voulez récolter, il serrait facile d'améliorer la description de l'objet
> dans osm si nécessaire
> 
> 2) potable ou non potable ? légalement ou en pratique ?
> tant un point d'eau qu'une fontaine peux fournir de l'eau potable
> ou non ou potable sans garantie légale
> Pour ma part, je m'en tiens à la page wiki
> https://wiki.openstreetmap.org/wiki/Key%3Adrinking_water
> s'il y a un panneau potable ou si c'est manifestement fait pour se
> désaltérer (cas du mobilier urbain avec un robinet ou bouton poussoir)
> amenity=drinking_water ou drinking_water:legal=yes sur une fontaine
> s'il y a un panneau non potable drinking_water:legal=no
> s'il me semble raisonnable de boire l'eau drinking_water=yes
> s'il me semble déraisonnable de boire l'eau drinking_water=no
> 
> Cordialement,
> Marc
> 
> Le 07.01.20 à 15:45, European Water Project a écrit :
> > Bonjour, 
> >
> > Nous avons les instructions maintenant en 6 langues pour comment
> ajouter
> > une fontaine en OpenStreetMap et une photo d'une fontaine en Wikimedia
> > Commons. Nous avons eu beaucoup d'aide pour completer cette tache
> d'OSM
> > Suisse et d'OSM Espagne.
> >
> >
> 
> https://meta.wikimedia.org/wiki/Wikimedia_CH/Project/European_Water_Project/fr
>    
> >
> > Stefan Keller d'OSM Suisse nous conseil de mettre comme tag pour la
> > grande majorité de fontaines que  "amenity=drinking_water" et de
> ne pas
> > mettre 2) "amenity=fountain et drinking_water=yes".  Vous etes plutôt
> > d'accord ? Malheureusement en France, la grande majorité de
> fontaines en
> > pierre avec de l'eau 100% potable sont libellée "non potable" par peur
> > du procès des maires (et ils ont raisons, tant que la legislation ne
> > change). Dans ce cas, faut-il mettre "amenity=fountain et
> > drinking_water=no".  Et si un jour la legislation change pour ces
> > fontaines, on mettra que "amenity=drinking_water" ?
> >
> > Bien cordialement,
> >
> > Stuart 
> >
> >
> >
> > On Fri, 27 Dec 2019 at 14:13, European Water Project
> >  
>  >>
> > wrote:
> >
> >     Bonjour, 
> >
> >      
> >
> >     Je serai reconnaissant si vous pouvez nous donner vos commentaires
> >     sur les instructions en français de comment ajouter une fontaine
> >     d’eau potable dans OpenStreetMap et une photo d’une photo dans
> >     Wikimedia Commons.
> >
> >      
> >
> >     Nous présentons le projet et l'application pour la première
> fois le
> >     8 janvier devant 860 lycéens de 48 pays - dont la moitie
> francophone. 
> >
> >      
> >
> >   
>  
> 

Re: [OSM-talk-fr] Comment libeller une fontaine d'eau en pierre (qui n'est pas un monument) ?

[European Water Project]

Merci Marc

Pour les fontaines qui sont indiquées "non potable", nous ne pouvons
qu'inciter les personnes de ne pas libeller la fontaine comme autre chose
que "amenty=fountain et drinking_water=no". Nous ne pouvons pas assurer de
la qualité de l'eau sans que les testes (qui ne sont pas couteux) soit
faites par les autoritées compétentes et je ne prendrai pas cette
responsabilité.

Et dans ce cas,  il y a une incoherence entre une belle fontaine en pierre
dans un village français qui sera juste "amenity=drinking_water" is l'eau
est potable, et "amenity=fountain" et "drinking_water=no" si la fontaine
n'est pas potable.

bien cordialement,

Stuart

On Tue, 7 Jan 2020 at 16:05, marc marc via Talk-fr <
talk-fr@openstreetmap.org> wrote:

> Bonjour,
>
> il y a 2 points différents dans ta question
>
> 1) à quoi ressemble l'objet ?
> la différence entre amenity=drinking_water <> amenity=fountain
> concerne l'apparence.
> un simple robinet d’où coule de l'eau avec une plaque d'égout en
> dessous, ce n'est pas une fontaine.
> un objet artistique, avec parfois plusieurs jets ou sculpté a des chance
> d'être une fontaine.
> évidement le problème est entre les 2 (ex un objet en pierre sculpté
> avec un simple jet d'eau). mais je suis d'accord avec Stefan : à priori
> quand il y a un doute, c'est un amenity=drinking_water
> il ne serrait d'ailleurs pas trop grave de mettre amenity=drinking_water
> sur une fontaine, osm se fait de manière incrémentielle, une fois la
> localisation précise connue, et qui plus est grâce aux photos que vous
> voulez récolter, il serrait facile d'améliorer la description de l'objet
> dans osm si nécessaire
>
> 2) potable ou non potable ? légalement ou en pratique ?
> tant un point d'eau qu'une fontaine peux fournir de l'eau potable
> ou non ou potable sans garantie légale
> Pour ma part, je m'en tiens à la page wiki
> https://wiki.openstreetmap.org/wiki/Key%3Adrinking_water
> s'il y a un panneau potable ou si c'est manifestement fait pour se
> désaltérer (cas du mobilier urbain avec un robinet ou bouton poussoir)
> amenity=drinking_water ou drinking_water:legal=yes sur une fontaine
> s'il y a un panneau non potable drinking_water:legal=no
> s'il me semble raisonnable de boire l'eau drinking_water=yes
> s'il me semble déraisonnable de boire l'eau drinking_water=no
>
> Cordialement,
> Marc
>
> Le 07.01.20 à 15:45, European Water Project a écrit :
> > Bonjour,
> >
> > Nous avons les instructions maintenant en 6 langues pour comment ajouter
> > une fontaine en OpenStreetMap et une photo d'une fontaine en Wikimedia
> > Commons. Nous avons eu beaucoup d'aide pour completer cette tache d'OSM
> > Suisse et d'OSM Espagne.
> >
> >
> https://meta.wikimedia.org/wiki/Wikimedia_CH/Project/European_Water_Project/fr
>
> >
> > Stefan Keller d'OSM Suisse nous conseil de mettre comme tag pour la
> > grande majorité de fontaines que  "amenity=drinking_water" et de ne pas
> > mettre 2) "amenity=fountain et drinking_water=yes".  Vous etes plutôt
> > d'accord ? Malheureusement en France, la grande majorité de fontaines en
> > pierre avec de l'eau 100% potable sont libellée "non potable" par peur
> > du procès des maires (et ils ont raisons, tant que la legislation ne
> > change). Dans ce cas, faut-il mettre "amenity=fountain et
> > drinking_water=no".  Et si un jour la legislation change pour ces
> > fontaines, on mettra que "amenity=drinking_water" ?
> >
> > Bien cordialement,
> >
> > Stuart
> >
> >
> >
> > On Fri, 27 Dec 2019 at 14:13, European Water Project
> > mailto:europeanwaterproj...@gmail.com>>
> > wrote:
> >
> > Bonjour,
> >
> >
> >
> > Je serai reconnaissant si vous pouvez nous donner vos commentaires
> > sur les instructions en français de comment ajouter une fontaine
> > d’eau potable dans OpenStreetMap et une photo d’une photo dans
> > Wikimedia Commons.
> >
> >
> >
> > Nous présentons le projet et l'application pour la première fois le
> > 8 janvier devant 860 lycéens de 48 pays - dont la moitie
> francophone.
> >
> >
> >
> >
> https://meta.wikimedia.org/wiki/Wikimedia_CH/Project/European_Water_Project/fr
>
> >
> >
> >
> > Bien cordialement,
> >
> >
> >
> > Stuart Rapoport
> >
> >
> >
> > ___
> > 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] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[marc marc]

Bonjour,

Le 07.01.20 à 16:01, Quentin Salles a écrit :
> Pouvez-vous me confirmer que l'usage de la clé "ref:FR:gdo" est bien actif ?

Nous n'avions pas terminé la discussion sur la migration.
Je te conseille d'utiliser l'ancienne clef en attendant, puisque
c'est elle qui est la façon de faire actuellement.

Pour ma part, je me posais la question de ce que je considère comme
une surutilisation non nécessaire des espaces de nom (l’enchaînement
de clef: pour préciser une clef)
je vais faire une comparaison avec les routes :
en lisant une référence sur le panneau d'une route, cette référence
se retranscrit dans la clef ref=numéro et ceci indépendamment de
l'opérateur ou du pays.
on n'utilise pas non plus d'espace de nom du genre ref:FR:auteur
pour préciser qui serrait l'auteur de la ref.
on n'utilise pas non plus de mot dans la clef pour donner le sens de
cette référence ou le terme légal que celui-ci aurait dans la loi.

A l'inverse, dans le domaine énergétique (et des transports), au fil
du temps, on utilise des espaces de nom pour la clef ref en France,
sans que je perçoive ni le besoin ni même l'intérêt.

Au final l'utilisateur qui lit une ref quelque part, ne peux pas
l'ajouter dans osm sans devoir chercher dans le wiki quel est la règle
particulière qui régit cet objet dans ce pays.
cela nuit à mon avis grandement à l'encodage simple et même à
l'utilisation (essayez donc de connaître le nombre de power=substation
au niveau mondial qui ont une ref, vous devez écrire une règle qui dit
que cela peux être ref ou ref:* chose que de nombreux outil tel que
tainfo ou overpass ne permettent pas ou pas facilement)

> Est-il possible de remonter l'information
> via l'Open data. Si oui, est-il permis d'ajouter ces informations non
> visibles sur le terrain ?

bien sur, osmose ne propose rien sur le sujet ?
https://osmose.openstreetmap.fr/fr/map/

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

Re: [OSM-talk-fr] Comment libeller une fontaine d'eau en pierre (qui n'est pas un monument) ?

[marc marc via Talk-fr]

Bonjour,

il y a 2 points différents dans ta question

1) à quoi ressemble l'objet ?
la différence entre amenity=drinking_water <> amenity=fountain
concerne l'apparence.
un simple robinet d’où coule de l'eau avec une plaque d'égout en
dessous, ce n'est pas une fontaine.
un objet artistique, avec parfois plusieurs jets ou sculpté a des chance
d'être une fontaine.
évidement le problème est entre les 2 (ex un objet en pierre sculpté
avec un simple jet d'eau). mais je suis d'accord avec Stefan : à priori
quand il y a un doute, c'est un amenity=drinking_water
il ne serrait d'ailleurs pas trop grave de mettre amenity=drinking_water
sur une fontaine, osm se fait de manière incrémentielle, une fois la
localisation précise connue, et qui plus est grâce aux photos que vous
voulez récolter, il serrait facile d'améliorer la description de l'objet
dans osm si nécessaire

2) potable ou non potable ? légalement ou en pratique ?
tant un point d'eau qu'une fontaine peux fournir de l'eau potable
ou non ou potable sans garantie légale
Pour ma part, je m'en tiens à la page wiki
https://wiki.openstreetmap.org/wiki/Key%3Adrinking_water
s'il y a un panneau potable ou si c'est manifestement fait pour se
désaltérer (cas du mobilier urbain avec un robinet ou bouton poussoir)
amenity=drinking_water ou drinking_water:legal=yes sur une fontaine
s'il y a un panneau non potable drinking_water:legal=no
s'il me semble raisonnable de boire l'eau drinking_water=yes
s'il me semble déraisonnable de boire l'eau drinking_water=no

Cordialement,
Marc

Le 07.01.20 à 15:45, European Water Project a écrit :
> Bonjour, 
> 
> Nous avons les instructions maintenant en 6 langues pour comment ajouter
> une fontaine en OpenStreetMap et une photo d'une fontaine en Wikimedia
> Commons. Nous avons eu beaucoup d'aide pour completer cette tache d'OSM
> Suisse et d'OSM Espagne.
> 
> https://meta.wikimedia.org/wiki/Wikimedia_CH/Project/European_Water_Project/fr
>    
> 
> Stefan Keller d'OSM Suisse nous conseil de mettre comme tag pour la
> grande majorité de fontaines que  "amenity=drinking_water" et de ne pas
> mettre 2) "amenity=fountain et drinking_water=yes".  Vous etes plutôt
> d'accord ? Malheureusement en France, la grande majorité de fontaines en
> pierre avec de l'eau 100% potable sont libellée "non potable" par peur
> du procès des maires (et ils ont raisons, tant que la legislation ne
> change). Dans ce cas, faut-il mettre "amenity=fountain et
> drinking_water=no".  Et si un jour la legislation change pour ces
> fontaines, on mettra que "amenity=drinking_water" ?
> 
> Bien cordialement,
> 
> Stuart 
> 
> 
> 
> On Fri, 27 Dec 2019 at 14:13, European Water Project
> mailto:europeanwaterproj...@gmail.com>>
> wrote:
> 
> Bonjour, 
> 
>  
> 
> Je serai reconnaissant si vous pouvez nous donner vos commentaires
> sur les instructions en français de comment ajouter une fontaine
> d’eau potable dans OpenStreetMap et une photo d’une photo dans
> Wikimedia Commons.
> 
>  
> 
> Nous présentons le projet et l'application pour la première fois le
> 8 janvier devant 860 lycéens de 48 pays - dont la moitie francophone. 
> 
>  
> 
> 
> https://meta.wikimedia.org/wiki/Wikimedia_CH/Project/European_Water_Project/fr
>   
> 
>  
> 
> Bien cordialement,
> 
>  
> 
> Stuart Rapoport
> 
> 
> 
> ___
> 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] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[Quentin Salles]

Bonjour,

Pouvez-vous me confirmer que l'usage de la clé "ref:FR:gdo" est bien actif ?
En faisant une requête Overpass, je n'ai vu qu'une seule utilisation sur
toute la France.

De plus, je suis novice sur le sujet, mais je pense qu'il serait
intéressant de parler d'autres cas (notamment le gaz) sur cette page. Qu'en
pensez-vous ?

Sur le terrain, je ne trouve pas beaucoup de référence sur les armoires,
mais quasiment que des noms. Est-il possible de remonter l'information via
l'Open data. Si oui, est-il permis d'ajouter ces informations non visibles
sur le terrain ?

Bonne journée

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

[OSM-talk-fr] Comment libeller une fontaine d'eau en pierre (qui n'est pas un monument) ?

[European Water Project]

Bonjour,

Nous avons les instructions maintenant en 6 langues pour comment ajouter
une fontaine en OpenStreetMap et une photo d'une fontaine en Wikimedia
Commons. Nous avons eu beaucoup d'aide pour completer cette tache d'OSM
Suisse et d'OSM Espagne.

https://meta.wikimedia.org/wiki/Wikimedia_CH/Project/European_Water_Project/fr


Stefan Keller d'OSM Suisse nous conseil de mettre comme tag pour la grande
majorité de fontaines que  "amenity=drinking_water" et de ne pas mettre 2)
"amenity=fountain et drinking_water=yes".  Vous etes plutôt d'accord ?
Malheureusement en France, la grande majorité de fontaines en pierre avec
de l'eau 100% potable sont libellée "non potable" par peur du procès des
maires (et ils ont raisons, tant que la legislation ne change). Dans ce
cas, faut-il mettre "amenity=fountain et drinking_water=no".  Et si un jour
la legislation change pour ces fontaines, on mettra que
"amenity=drinking_water" ?

Bien cordialement,

Stuart



On Fri, 27 Dec 2019 at 14:13, European Water Project <
europeanwaterproj...@gmail.com> wrote:

> Bonjour,
>
>
>
> Je serai reconnaissant si vous pouvez nous donner vos commentaires sur les
> instructions en français de comment ajouter une fontaine d’eau potable dans
> OpenStreetMap et une photo d’une photo dans Wikimedia Commons.
>
>
>
> Nous présentons le projet et l'application pour la première fois le 8
> janvier devant 860 lycéens de 48 pays - dont la moitie francophone.
>
>
>
>
> https://meta.wikimedia.org/wiki/Wikimedia_CH/Project/European_Water_Project/fr
>
>
>
>
> Bien cordialement,
>
>
>
> Stuart Rapoport
>
>>
>>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BD Ortho down... donc UP du plan B

[Christian Quest]

Le 07/01/2020 à 13:58, Christian Quest a écrit :
Les appels de notre proxy à la BD Ortho sont rejetés (403 problème 
d'authentification).


Comme le site "pro" de l'IGN est indisponible depuis une dizaine de 
jours pour cause de migration version un futur nouveau site plus 
mieux, impossible d'aller voir ce qui coince, si il y a une clé à 
mettre à jour ou autre.


En attendant, je redirige les requêtes vers la couche "tous_fr" de 
wms.openstreetmap.fr


Elle ne couvre pas toute la France mais c'est mieux que rien du tout.



Rectificatif... l'IGN ne répond plus en HTTP mais uniquement en HTTPS et 
redirige les requêtes, que le proxy ne suivait pas. C'est désormais 
corrigé et retour à la normale.


Désolé pour le bruit !


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Mentions légales

[marc marc]

Le 07/01/2020 à 09:43, Xavier BIZOT a écrit :

> Comment faire lorsque la mention OSM
> n'est pas présente sur la carte

https://wiki.openstreetmap.org/wiki/FR:Manque_d%27attribution_appropri%C3%A9e
est-ce ceci que tu cherches ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] BD Ortho down... donc UP du plan B

[Christian Quest]

Les appels de notre proxy à la BD Ortho sont rejetés (403 problème 
d'authentification).


Comme le site "pro" de l'IGN est indisponible depuis une dizaine de 
jours pour cause de migration version un futur nouveau site plus mieux, 
impossible d'aller voir ce qui coince, si il y a une clé à mettre à jour 
ou autre.


En attendant, je redirige les requêtes vers la couche "tous_fr" de 
wms.openstreetmap.fr


Elle ne couvre pas toute la France mais c'est mieux que rien du tout.


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] SPAM, Mentions légales

[Christian Quest]

Le 07/01/2020 à 12:57, Jérôme Villafruela a écrit :

Le 07/01/2020 à 12:19, Arnaud Champollion a écrit :


Dans les coupables il y a aussi :

http://www.inforoute04.fr/

et

https://www.inforoutefrance.fr/


Ou bien je n'ai pas bien vu.


La mention "© OpenStreetMap contributors" (avec lien vers 
http://www.openstreetmap.org/copyright) est affichée lorsqu'on clique 
sur l'icône roue dentée, donc c'est presque bon.



Ça pourrait être pire, mais ça pourrait être mieux.

La page copyright d'OSM est claire, quand il y a la place, ça doit être 
directement visible.


Openlayers n'est pas pratique pour montrer directement les attributions, 
du coup il faut coder... ce qui est rarement fait.


--

Christian Quest - OpenStreetMap France


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

Re: [Talk-it] Violazione (c) - CCISS.it

[Francesco Pelullo]

Il mar 7 gen 2020, 10:27 Alessandro Sarretta 
ha scritto:

> Ciao,
>
> ho segnalato anch'io via Twitter (
> https://twitter.com/alesarrett/status/1214477116110192641) e via e-mail.
>
> Ale
>
L'avevo fatto anch'io:

https://twitter.com/fpelullo/status/1214189266693246977

Dalla regia mi giunge notizia che è stato inviata segnalazione direttamente
ai ai piani alti, aspettiamo gli esiti.

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

Re: [talk-au] Over 55’s Lifestyle Village = retirement_home ?

[Sebastian S.]

Sounds simple. Village details then on the residential area?

Often there are shared things such as pool, meeting hall etc. How would they be 
tagged then?

On 7 January 2020 9:17:19 am AEDT, Graeme Fitzpatrick  
wrote:
>> > Hi all,
>> >
>> > is a Over 55’s Lifestyle Village (like this one
>> > https://www.middlerockhomevillage.com.au) a
>amenity=retirement_home?
>>
>
>One near us  https://www.openstreetmap.org/way/209449523 has been
>marked
>simply as
>
>landuse=residential
>name=Miami Retirement Village
>min_age=50
>
>Thanks
>
>Graeme
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Over 55’s Lifestyle Village = retirement_home ?

[Sebastian S.]

I can confirm these observations for another similar site I've visited.

On 7 January 2020 7:30:48 am AEDT, fors...@ozonline.com.au wrote:
>Hi
>Looking at the photos and site plan I suspect the homes may be  
>demountable, that is, on temporary foundations. Sorry , I am not  
>directly answering the tagging question, Even if purpose built it may  
>effectively be a caravan park with all the sites taken by onsite  
>cabins. Typically the site is leased but the building is owned by the  
>resident.
>
>They allow for greater density than strata plan units. The demountable 
>
>construction allows the fiction that these buildings could ever be  
>moved.
>
>Tony
>
>
>> Hi all,
>>
>> is a Over 55’s Lifestyle Village (like this one
>> https://www.middlerockhomevillage.com.au) a amenity=retirement_home?
>>
>> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dretirement_home
>>
>> I'm not clear if the Lifestyle Village is only a fancy marketing name
>or
>> not. I've seen such villages and some are past caravan parks that
>have
>> been re-purposed with the over 55's as clientel.
>>
>> How would you tag this?
>>
>>
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>>
>> _
>> This mail has been virus scanned by Australia On Line
>> see http://www.australiaonline.net.au/mailscanning
>>
>
>
>
>
>
>___
>Talk-au mailing list
>Talk-au@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-au
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-it] Violazione (c) - CCISS.it

[Martin Koppenhoefer]

si, anche a Roma OSM.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Violazione (c) - CCISS.it

[Volker Schmidt]

A Padova: sicuramente OSM, più di otto mesi indietro

On Tue, 7 Jan 2020 at 10:54, Federico Cortese  wrote:

> On Tue, Jan 7, 2020 at 8:21 AM Massimo Taronna
>  wrote:
> >
> > Sicuramente mappe OSM, ma vecchie di almeno 2 anni, guardando la
> situazione nella mia zona
> >
>
> Confermo, sicuramente mappe OSM, ma molto vecchie.
>
> Ciao,
> Federico
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] SPAM, Mentions légales

[Jérôme Villafruela]

Le 07/01/2020 à 12:19, Arnaud Champollion a écrit :


Dans les coupables il y a aussi :

http://www.inforoute04.fr/

et

https://www.inforoutefrance.fr/


Ou bien je n'ai pas bien vu.


La mention "© OpenStreetMap contributors" (avec lien vers 
http://www.openstreetmap.org/copyright) est affichée lorsqu'on clique 
sur l'icône roue dentée, donc c'est presque bon.


--
Jérôme


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

Re: [OSM-talk] [Tagging] Tagging the local language

[Martin Constantino–Bodin]

(By the way, I really appreciate the arguments that are given in this 
thread: we’re doing good work here! ☺)


So, it seems that we can’t really make these changes to the OSM database 
because there are technical issues in the OSM renderrers to be solved 
first. In particular, it is currently very difficult to know what is the 
local language(s) to be used in a given area in a map, and we thus 
heavily rely on the “name” tag to display names on the map.


From what you said, you seem very fine with the suggestion to remove 
the “name” tag in regions with no main local language, as soon as there 
is some way to infer the local languages. Please tell me if I’ve 
misunderstand you on this part ☺


If so, we are “only” left with the issue of agreeing with a way to map 
this information, and update the main renderrers. (Both are huge tasks, 
I’m fully aware of that ​)


The proposal that Joseph Eisenberg linked ( 
https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format 
) is very interesting. From what I saw, it seems that it was rejected 
for two reasons: first because linguistic regions are fuzzy and thus 
hard to map, and second because it wasn’t very clear what to do if there 
are more than one language (I mean, it does states that we can separate 
language codes by semicolons, just that some people in the votes seem 
not to know what to render from it if too many languages are listed). It 
seems to me that these are actually very close to the issues that we 
discussed in this thread: we are in a good direction ☺


Mario Frasca noted that the areas that we are discussing (Antarctica, 
Seas, etc.) are actually all regions, not POIs! I completely missed that 
before. So we could definitely choose to put multiple labels, and we can 
even choose to place them next to the corresponding linguistic area. 
This is a cool idea ☺


one reason for mentioning Morocco: it shows how three names is 
perceived as too many.  the impact on South America could be to name 
it in Spanish and Portuguese (two languages), and by this we would 
cover more than 99% of the people living there.  North America would 
need Spanish, English and French, so maybe that would be one language 
too many.


Maybe we can sometimes factorise? Like “América del Sur / do Sul” for 
South America. (Technically, France is partly in South America too, but 
I guess that it is completely fine to forget about it in the same way 
that we can forget about Pomerode when naming the continent because, as 
you said, Spanish and Portuguese covers 99 % of the population.)


(interesting page, that about "Imperialisme linguistique".  the Dutch 
version of it, very short, mentions Morocco for the other reason I 
mentioned it myself: the country has experienced French and Arabic 
cultural imperialism, and is now trying to implement some respect for 
the majority of their (Amazigh) people.  taken to this context, this 
would be the OSM-people who do not read nor write to this list.  mind 
you, the list is called 'talk', not 'talk:en'.)
Indeed, that’s a very good point. And I guess that most OSM mappers are 
actually not following this list. I’m not sure what we can do about that 
here :-\
Interlingua/Lingua Franca would be a nice compromise, at least for 
South America and the seas next to Spain, France, and Italy, where 
more than three languages are recognized and even more spoken, but all 
are neo-latin.  I don't know whether anything like this could apply to 
the Baltic, or to other seas.


The advantage of Interlingua is that it has been designed to be 
understandable without having to learn the language by a large part of 
the European community. It indeed may be a good choice for an 
international map (in the places where there is no obvious local 
language). However, it feels like this should be a choice left to the 
renderrer, not the OSM database. That’s why I would be in favor of any 
additional tag as you suggested above.


About the Baltic Sea, maybe the Interslavic language and its children 
(Slovianto, Neoslavonic) would be possible candidates? It will be 
difficult to choose anyway, as the Finnish language has very different 
origin than the other languages spoken in the region. That’s in general 
why I don’t think that there should be only one language… but as people 
considers that more than two languages is too much on the map, some 
choice will have to be made.


anyhow, leaving implementations aside, I think that a bit more 
language-culture agnosticism would not harm OSM. 


I fully agree ☺ And I think that this would be a great value for the OSM 
community over the world. ​


Regards,
Martin.


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

Re: [Talk-it] admin_level per Quartieri e Consulte

[Volker Schmidt]

Interessante.
Io ho guardato la topologia inerente all'organizzazione:
Quartiere 1 = Consulta 1
Quartiere 2 = Consulta 2
Quartiere 3 = Consulta 3A + Consulta 3B
Quartiere 4 = Consulta 4A + Consulta 4B
Quartiere 5 = Consulta 5A + Consulta 5B
Quartiere 6 = Consulta 6A + Consulta 6B

Sotto questo aspetto
vedo

   - Città: admin_level 8
   - Quartiere: admin_level 10 (non 9, solo perché ho visto in altre città
   che Quartieri/Circonscrizioni sono stati taggati con 10, non conosco il
   motivo)
   - Consulta: admin_level 11


Poi ci sono a Padova 31 place=suburb con name e population che sono stati
inseriti a Padova dal utente fayor come parte di un singolo mega-changeset
, senza commenti e fonti
ecc.
Questo è stato discusso  in questa lista nel 2016-2017 (" [Talk-it] R:
Utente che modifica confini") ma in modo non conclusivo, se ho capito bene.
Non so a quali entità amministrative questi suburb si riferiscono.



On Tue, 7 Jan 2020 at 10:30, Alessandro Sarretta <
alessandro.sarre...@gmail.com> wrote:

> Ciao Volker,
>
> attenzione però che a Padova le Consulte dovrebbero essere a un livello
> più alto dei quartieri, poiché (tutte a parte il Centro) sono aggregazioni
> di vari quartieri:
> http://padovanet.it/informazione/le-consulte-di-quartiere
>
> Ale
> On 07/01/20 00:20, Volker Schmidt wrote:
>
> Vorrei aggiungere a Padova i Quartieri e le Consulte di Quartiere
> Pensavo di utilizzare admin_level=10 per Quartieri.
> Sono incerto sulle Consulte di Quartiere,con admin_level=11
>
> Volker
>
> ___
> Talk-it mailing 
> listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] SPAM, Mentions légales

[Arnaud Champollion]

Le 07/01/2020 à 09:43, Xavier BIZOT a écrit :

https://quefaire.net/cotes_d_armor/pledran/randonnee_pedestre_117443266.htm

est utilisateur de la carte mais sans menti



Dans les coupables il y a aussi :


http://www.inforoute04.fr/

et

https://www.inforoutefrance.fr/


Ou bien je n'ai pas bien vu.

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

Re: [OSM-talk] JOSM: hover-Coordinate into clipboard by easy click or a wink?

[tshrub]

Am 07.01.20 um 03:02 schrieb Wayne Emerson, Jr. via talk:
I don't know if JOSM can do that, but in the iD editor 

yes it works. Thanks! :-)



id-editor
https://www.openstreetmap.org
on top-bar: edit ...


the josm-lack this is impossible too - like the lack of a default search 
gui in Ubuntu. Handstand in front of the desk. We're all gonna doie.


best






you can press 
Ctrl-Shift-M to open the Measurement box, then place a node where you 
need coordinates. Click on the node, then select the coordinate text in 
the Measurement box and press Ctrl-C.


On 1/6/2020 8:39 PM, tshrub wrote:

hi,

in JOSM's status bar the mouse position is constantly running as a 
coordinate. Is there any easy way to get it, may be by keyboard into 
the clipboard?
I want to edit GPS data from, or better: add GPS-data to trackless 
photos - I want to place them like this with JOSM' sat-pictures.


bella saluti


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

Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[Martin Constantino–Bodin]

Baltic Sea to be the "Baltic Sea" or for South America to be "South

America" - this is an example of English imperialism.

This "imperialism" idea of yours is just your idea. It is not
something that is widely felt.


regarding imperialism, I think it’s hard to reject the reasoning
that English is in widespread use because of imperialism.

Yes, but using it for a pragmatic reasons
for an international communication is
usually not imperialism.


I am also not a fan of blaming history for the current situation and 
taking the long road because you don't like that history.
It would mean that I couldn't speak dutch with my Surinam friends just 
because 400 years ago the ideas of how we should conduct ourselves 
were different.


That is just counterproductive. 


Indeed. But it should be taken with some care.

In particular there is a huge difference between using English as a 
vehicular language, and using US or UK base culture references. A simple 
example of this is the imperial system: it is currently in use in very 
few countries (and even here in the UK, it has mostly been replaced by 
metric measures everywhere). Yet, you will see a lot of people using 
these depreciated units just because they think that it comes with the 
English package. This is very sad for me.


Another think to keep in mind is that English is a difficult language. 
There is a scientific consensus in this, and yet a lot of people seems 
to deny this based on bare opinion (usually held people speaking less 
than three languages…). Thus, is it extremely important, in the sake of 
equality, that when a native is discussing with a non-native with 
difficulties speaking or understanding, that the native avoid unusual 
words, idioms, etc. Doing otherwise would be a very effective way to 
make the non-native feel stupid, or to just not listen to him/her 
because “he/she doesn’t understand”… which is just a perfect 
illustration of the consequences of imperialism.


One of the base of the Esperanto movement, but also the simple/basic 
English Wikipedia project, was precisely to fight against these 
inequalities caused by the difficulty of the French and English 
languages in a constructive way. (It’s not the only goals of these 
movements.)


In short, indeed there has been a lot of past imperialism, but these 
kind of things can be insidious and still continue. I really don’t think 
that we want to unconsciously impose such culture in our community. This 
is why I believe that we should be very careful with people trying to 
impose an English name for the “name” tag in places where it is 
absolutely not fit (see 
https://www.openstreetmap.org/node/424311641/history for a sad example). 
Or state that this mailing list is English-only knowing that someone 
subscribing to it is not warned about it beforehand.


Regards,
Martin.


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

Re: [talk-au] Calling all geogeeks in the Sydney region!

[Andrew Harvey]

I've prepared some MapRoulette challenges for Thursday would appreciate any
comments from the community if you see any issues with this. (we have the
waiver for NPWS datasets)

1. NPWS (air) Landing Sites. The task is to check this on the imagery, and
either create an https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dhelipad
or https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dlanding_site if none
already exists in OSM. I'm also asking for a surface tag where possible
and operator=National Parks and Wildlife Service +
operator:wikidata=Q6974770 where the source data indicates NPWS is the
owner. Useful to know in an emergency and need air evacuation.

2. NSW Fire Station Operators, aharvey, daviewales, ConsEbt, ortho_is_hot
have all contributed on this one and we've fixed 22% already. The emphasis
here on using either the implied name of RFB/RFS or the NSW LPI Basemap to
provide a clear answer on when the NSW RFS operator and operator:wikidata
tags should be applied. (useful to know where the rural fire brigades are
located)

3. NPWS (water) Landing Sites. Wharfs, pontoons, slipways and boatramps.
I'm asking users to confirm this from the imagery and map in OSM if not
existing. Useful when roads are closed due to fires and you need another
way out.

4. NPWS Roads. This is mostly fire trails or other management trails. I've
done a comparison to identify roads from their data not already in OSM, the
task is asking people to check this on aerial imagery and possibly also the
NSW LPI Basemap and if it's all confirming the same thing then map it.
These roads can be useful for fire management, but also tagging the surface
and 4wd_only can be helpful to in knowing routes which would be ill advised
to take in a 2wd car.

I am very conscious that to not ask people to blindly import and make the
map worse, so trying to only do this where we have a few sources all
agreeing with a high confidence.

On Sun, 5 Jan 2020 at 14:43, Andrew Harvey  wrote:

> For those in in Sydney, quoting from John Bryant's announcement at
> https://t.co/r80D9yNw0h?amp=1 ...
>
> With Andrew Harvey & Stella Blake-Kelly, we're pulling together an
> informal, hands-on, geospatial social hacking/training/meetup session,
> around the general theme of bushfires and maps.
>
> A couple of ideas for activities (but also, bring your own ideas):
> - OSM mapathon (mapping & tagging isolated buildings, bushland, and other
> relevant points of interest)
> - desktop mapping and coding with various sources of bushfire spatial data
>
> It's about learning, sharing what you know, and making friends in the
> geospatial community. All welcome. Bring a laptop!
>
> When: Thursday 9th January, 6pm
> Where: Vibewire, 525 Harris St, Ultimo
>
> Huge thanks to Vibewire for providing the space, and OSGeo Oceania for
> providing pizza.
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-es] Unificar vías con carriles separados

[David Marín Carreño]

Hola, YoPaseoPor:

Sobre el access=no, según la página del wiki sobre la etiqueta access,(
https://wiki.openstreetmap.org/wiki/Key:access) creo que es correcto
etiquetar una vía sólo-bus como: access=no, psv=bus

Sobre el resto de etiquetas, el tema es que ese carril va en contrasentido
al resto de carriles. Y en el sentido "normal" también existe otro carril
bus.

Creo que, dado que en ciertos lugares se está "difuminando" la idea de "si
no hay separación física, usar una sola vía" (como en el caso de las
aceras), simplifica en sobre manera tanto los renderizadores como los
enrutadores mapearlo así. Siempre sin querer caer en un caso de "mapear
para el renderizador" o el "enrutador", sino en hacerlo como buenamente
consideremos sensato para que el que venga detrás entienda de qué estamos
hablando

Un cordial saludo.
--
David Marín Carreño 



El dom., 5 ene. 2020 a las 14:26, yo paseopor ()
escribió:

> Mirándomelo con detenimiento...no estoy de acuerdo.
>
> Primero, porque el etiquetaje creo que no es correcto. Me gustaría si
> alguien puede confirmar que ese Paseo de las Delicias funciona
> correctamente, porque tengo mis serias dudas, especialmente para autobuses:
> access=no  ¡¿Acceso prohibido?! ¿¿Entonces los buses no pueden
> pasar??
> highway=residential
> lanes=1
> name=Paseo de las Delicias
> oneway=yes
> psv=bus
> surface=asphalt
>
> existe la etiqueta psv:lanes=designated
> existe la etiqueta lanes:psv=1
> existe bus=designated
> (Si sólo hay un carril y ese carril está dedicado al transporte público es
> evidente que no te van a permitir ir por ahí si no lo eres.)
>
> Por otro lado, en ese tramos concreto se podría usar las subetiquetas
> :forward y :backward
> Salut i mapes
> yopaseopor
>
> On Thu, Jan 2, 2020 at 7:41 AM David Marín Carreño 
> wrote:
>
>> Hola.
>>
>> Hay problemas que no se pueden solucionar si se unen.
>>
>> Por ejemplo, https://www.openstreetmap.org/#map=18/40.39254/-3.69499
>>
>> En ese tramo del Paseo de las Delicias hay un carril bus en sentido
>> contrario a la marcha. Desconozco si en la actualidad hay una separación
>> física de dicho carril o no. Sé que en su día no la había.
>>
>> Mapear esto sin independizar una vía para este carril bus, aunque no haya
>> separación física, es un auténtico caos. Y algo que es completamente claro
>> en la actualidad para cualquiera que vea el mapa o la base de datos se
>> convierte en un maremagnum de etiquetas difícilmente legibles e
>> interpretables para generadores de mapas, ruteadores, etc.
>>
>> En otros casos, unirlo puede ser correcto. Pero ojo con perder
>> información o añadir información de giros incorrecta. Quien haga esta
>> unificación ha de ser muy meticuloso con todo esto.
>>
>> Yo, sinceramente, abogo por dejarlo como está. No sé si podría crearse
>> una relación entre ambas vías, incluyendo las aceras si existen como vías
>> separadas.
>>
>> --
>> David Marín Carreño 
>>
>>
>>
>> El mié., 1 ene. 2020 a las 11:29, Héctor Ochoa ()
>> escribió:
>>
>>> Buenas,
>>> yo sí que estoy de acuerdo en la unificación, ya que no hay separación
>>> física. Si hubiese aunque sea unos míseros bolardos en la mediana,
>>> separado. Dicho eso, tampoco cambia mucho ponerlo de una manera o de otra
>>> pero creo que en este caso queda más correcto unirlas.
>>>
>>> Saludos
>>>
>>> El mié., 1 ene. 2020 a las 11:23, Miguel Sevilla-Callejo (<
>>> msevill...@gmail.com>) escribió:
>>>
 Hola,

 Yo NO soy partidario de unificar vías en calles que ya se han editado
 por separado y en el que ya hay relaciones y otros datos incluidos. Esto
 puede llevar a una simplificación y problemas con los ruteadores, entre
 otros.

 Estoy de acuerdo respecto a que si no hay una separación física no se
 separe, pero si tienes una calle con doble mediana y más de cuatro carriles
 me parece recomendable la separación. Y si no es así se puede seguir
 realizando con vías separadas y uniones en lugares en los que se pueda
 atravesar la otra calzada.

 Efectivamente todo se puede resolver con un buen etiquetado pero
 conforme nos acercamos al detalle y subimos de escala es recomendable la
 separación de vías.

 Sucede similar con las calles con aceras. Tras mucho pensar cómo
 realizar las ediciones, cuando llegas al detalle es recomendable la
 separación de la vía peatonal de la vehicular. Para trabajar en rutas,
 caracterización particular y añadir elementos extras se hace más práctico
 la separación.

 Se que no es exactamente lo mismo que lo que se plantea, pero antes de
 entrar en cambiar cosas que ya están editadas, yo sugiriría entrar en
 añadir más detalles y elementos. Perder vías será perder nodos y finalmente
 información.

 Un saludo y feliz 2020

 Miguel


 On Tue, 31 Dec 2019, 10:08 Roberto geb,  wrote:

> Alejandro,
>
> separar los sentidos de la marcha cuando hay una doble línea pintada

Re: [Talk-it] Violazione (c) - CCISS.it

[Federico Cortese]

On Tue, Jan 7, 2020 at 8:21 AM Massimo Taronna
 wrote:
>
> Sicuramente mappe OSM, ma vecchie di almeno 2 anni, guardando la situazione 
> nella mia zona
>

Confermo, sicuramente mappe OSM, ma molto vecchie.

Ciao,
Federico

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

[talk-cz] WeeklyOSM CZ 492

[Tom Ka]

Ahoj, je dostupné vydání 492 týdeníku WeeklyOSM:

https://weeklyosm.eu/cz/archives/12676

* CZ a SK překlad rad pro komentáře.
* Evoluce OSM v Irsku.
* Manuál Overpass API.
* Proč nový Switch2OSM?
* Den otevřených dat.
* Novinky iD v2.17.0.
* Nej mapy za 2019.
* Jak na obrázky týdne?
* Útoky na GPS v Číně.
* Návrh změn v Apple Maps.
* 35let klimatu Arktidy.
* GPS pro cyklisty s OSM.

Pěkné počtení ...

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

Re: [Talk-it] Violazione (c) - CCISS.it

[Alessandro Sarretta]

La segnalazione via e-mail è andata a vuoto perché perché il server 
e-mail della centrale operativa del CCISS è pieno... siam messi bene :-/


-

*Il recapito non è riuscito per i seguenti destinatari o gruppi:*

centroperativa.cc...@mit.gov.it 
La cassetta postale del destinatario è piena e non può accettare 
messaggi in questo momento. Riprova a inviare il messaggio più tardi.


-

Ale


On 07/01/20 10:26, Alessandro Sarretta wrote:


Ciao,

ho segnalato anch'io via Twitter 
(https://twitter.com/alesarrett/status/1214477116110192641) e via e-mail.


Ale

On 06/01/20 15:00, Francesco Pelullo wrote:

Ciao a tutti

Segnalo un altro caso di violazione della licenza di Openstreetmap:

https://www.cciss.it/web/cciss/situazione-della-viabilita

In questo caso, IMHO c'è addirittura malafede perché l'autore o gli 
autori della pagina espongono i credits sulla mappa al Ministero 
delle Infrastrutture e Trasporti.


Provvedo a segnalare tramite Twitter.

Ciao
/niubii/




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

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

[HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE PPE)]

Bonjour Christian,

Cette circulaire est-elle accessible quelque part ? Cela pourrait me servir de 
base pour solliciter les communes pour leurs plaques bilingues.
D'avance merci

Denis

-Message d'origine-
De : rainerU  
Envoyé : mardi 7 janvier 2020 09:50
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] pb sur un cset lié aux langues locales

Bonjour Christian,

Am 04.01.20 um 17:53 schrieb Christian Rogel:
>   * Après la création du rendu des NL en breton (avril 17), j’ai envoyé une
> circulaire à tous les organismes s’occupant de langues locales en France
> (offices publics, directions nationale et régionales, associations).

Si tu as envoyé cette circulaire à un organisme régional qui s'occupe de la 
langue catalane, peux-tu m'en envoyer les coordonnées ?

Rainer


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] admin_level per Quartieri e Consulte

[Alessandro Sarretta]

Ciao Volker,

attenzione però che a Padova le Consulte dovrebbero essere a un livello 
più alto dei quartieri, poiché (tutte a parte il Centro) sono 
aggregazioni di vari quartieri: 
http://padovanet.it/informazione/le-consulte-di-quartiere


Ale

On 07/01/20 00:20, Volker Schmidt wrote:

Vorrei aggiungere a Padova i Quartieri e le Consulte di Quartiere
Pensavo di utilizzare admin_level=10 per Quartieri.
Sono incerto sulle Consulte di Quartiere,con admin_level=11

Volker

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

Re: [Talk-it] Violazione (c) - CCISS.it

[Alessandro Sarretta]

Ciao,

ho segnalato anch'io via Twitter 
(https://twitter.com/alesarrett/status/1214477116110192641) e via e-mail.


Ale

On 06/01/20 15:00, Francesco Pelullo wrote:

Ciao a tutti

Segnalo un altro caso di violazione della licenza di Openstreetmap:

https://www.cciss.it/web/cciss/situazione-della-viabilita

In questo caso, IMHO c'è addirittura malafede perché l'autore o gli 
autori della pagina espongono i credits sulla mappa al Ministero delle 
Infrastrutture e Trasporti.


Provvedo a segnalare tramite Twitter.

Ciao
/niubii/




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

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

[rainerU]

Bonjour Christian,

Am 04.01.20 um 17:53 schrieb Christian Rogel:

  * Après la création du rendu des NL en breton (avril 17), j’ai envoyé une
circulaire à tous les organismes s’occupant de langues locales en France
(offices publics, directions nationale et régionales, associations).


Si tu as envoyé cette circulaire à un organisme régional qui s'occupe de la 
langue catalane, peux-tu m'en envoyer les coordonnées ?


Rainer


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

[OSM-talk-fr] Mentions légales

[Xavier BIZOT]

Bonjour à toutes et tous,

Tous mes meilleurs voeux pour cette nouvelle année 2020.

J'ai vu passé une discussion sur "Comment faire lorsque la mention OSM
n'est pas présente sur la carte", mais j'ai beaucoup de retard dans mes
mails, et je n'arrive pas à le retrouver.

Donc pour info :
https://quefaire.net/cotes_d_armor/pledran/randonnee_pedestre_117443266.htm

est utilisateur de la carte mais sans mention.

Amicalement,

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

Re: [OSM-talk-fr] 1ere mondiale (enfin je crois) : le réseau de transport électrique français est routable

[Vincent de Château-Thierry]

Bonjour,

> De: "Jean-Christophe Becquet" 
> 
> Le 07/01/2020 02:05, François Lacombe a écrit :
> > La complétude va permettre d'extraire une dizaine de jeux de
> > données
> > thématiques, dont la plupart n'a pas d'équivalent en données
> > ouvertes,
> > dans les prochaines semaines et de communiquer sur leur
> > disponibilité.
> 
> Bonjour et bonne année à tous,
> 
> Un grand bravo François pour avoir nourri cette dynamique et animé ce
> travail de contribution !

Oui bravo François pour ce marathon et son issue \o/
On ajoute avec cette étape un jeu de données national complet, ça a de la 
gueule !

vincent

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