date:20191219




20 Dec 2019, 01:25 by ba...@ursamundi.org:

> So, for example, in the US, instead of motorway, trunk, primary, secondary, 
> tertiary, perhaps something more like freeway, expressway, 
> major/minor_principal (just having this would fix a *lot* of problems with 
> Texas and Missouri and their extensive secondary systems), 
> major/minor_collector...the US just has a way more complex view of how 
> highways work.  
>
> Or at least some more serious consideration given to the proposal at > 
> https://wiki.openstreetmap.org/wiki/User:UltimateRiff/HFCS>  (but perhaps 
> with "other principal arterials" as primary and a new "highway=quartinary".
>
Fitting thing like road classification
into UK system is irritating at times.

But idea of each country with separate tags
for roads is simply a bad idea.

This info is probably worth recording,
but legal status should go into a separate tag.

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

Re: [OSM-legal-talk] use OSM data to select proprietary data




20 Dec 2019, 01:13 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>> On 20. Dec 2019, at 00:16, Kathleen Lu via legal-talk 
>>  wrote:
>>
>> This is not what the Substantial Guideline says. It says that fewer than 100 
>> features is "not Substantial". It also gives as an example "More that 100 
>> Features only if the extraction is non-systematic and clearly based on your 
>> own qualitative criteria for example an extract of all the the locations of 
>> restaurants you have visited for a personal map to share with friends or use 
>> the locations of a selection of historic buildings as an adjunct in a book 
>> you are writing, we would regard that as non Substantial."
>>
>
>
> If I recall correctly there is no definition what a feature is. Nobody has 
> yet commented how they would interpret this for a border: is it about the 
> border way or about the individual border points from which the border is 
> made of? 
>
Obviously, both nodes, ways and
relations should be counted.

Otherwise one would be able to
temporarily create one relation,
that would include all data (s)he
wish to use and export this.___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

[OSM-talk-fr] Osmose cachottier

2019-12-19 Per discussione Txo


Bonjour,

Je reçois par RSS les erreurs qui me concernent (de près ou de loin) 
signalées par Osmose.


Le flux RSS permettait jusqu'à maintenant d'avoir 2 modes d'accès aux 
erreurs. Une première adresse qui ouvrait une page dans le navigateur 
qui permettait elle même d'avoir accès à la carte avec l'erreur repérée.


Le second mode d'accès ouvre (toujours) directement JOSM mais sans 
repérer l'erreur.


Depuis quelque temps la première adresse butte sur

Error: 404 Not Found

File does not exist.

/
/
/api/0.2/error/
/api/0.2/error//
/api/0.2/error//fix […]

J'utilise Firefox sous Debian Sid. J'aimerai bien retrouver la 
localisation des erreurs.






--
-- Dominique Marin http://txodom.free.fr  --
   «On ne peut pas juger quelqu'un à ses fréquentations ;
   ne perdons pas de vue que Judas avait des amis irréprochables.»
--   Tristan Bernard  --

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

Re: [Talk-it] [talk-it] tagging accesso bici in Aree Pedonali

2019-12-19 Per discussione emmexx

On 12/20/19 1:57 AM, Martin Koppenhoefer wrote:
> io sconsiglio a tutti di farlo. Quando stavo ancora a Berlino è morta la 
> ragazza di un amico così: attraversando in bici sulle strisce, alle 10 di 
> mattina (la colpa era suo perché le macchine non si possono aspettare 
> qualcuno con la velocità di una bici sulle strisce, è oramai quasi 20 anni 
> fa, ma non credo siano cambiate le leggi, e anche se qui la situazione legale 
> potrebbe essere diversa, quella reale è più a sfavore di chi attraversa sulle 
> strisce direi)

Anche se c'è un parere ministeriale che sembra consentire il transito
sulle strisce pedonali senza scendere dalla bici, non tutti sono
d'accordo su questa interpretazione.
La sostengono la FIAB e Salvaiciclisti tra gli altri [1] e [2] ma l'ing.
Chiarini del gruppo tecnico della FIAB nel suo documento sugli
attraversamenti non ne parla [3]. E Chiarini di solito è bene informato
su questi argomenti.

In Italia è già pericoloso attraversare sulle strisce a piedi, farlo in
bici è purtroppo un tentativo di farsi del male.

Io attenderei prima di cambiare il modo di taggare gli attraversamenti
qualche sentenza della Cassazione in materia in cui viene esplicitamente
confermato o cassato il parere ministeriale di cui sopra.

ciao
maxx

[1]
www.fiab-onlus.it/bici/attivita/varie/item/download/95_1b2f0c85a70e781d96681238e4b570c2.html
[2] http://www.salvaiciclistiroma.it/strisce-in-bici-si-puo/
[3] www.studiochiarini.it/documenti/SM07_sito.pdf

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

Re: [talk-cz] [osm_sk] Re: Tip na překlad OSM wiki

2019-12-19 Per discussione Tom Ka

Ahoj, diky za preklad, koukam, ze Chrabros uz to poladil, za mne
precteno bez pripominek.

Bye tom.k

st 18. 12. 2019 v 14:01 odesílatel Jakub Jelen  napsal:
>
> Ahoj,
> prelozil jsem tu stranku do cestiny, ale najeke review a korektury
> urcite budou potreba, pokud mate nekdo chut a cas:
>
> https://wiki.openstreetmap.org/wiki/Cs:Good_changeset_comments
>
> Stejne tak to vypada, ze nemam prava k tomu ji presunout (pro cesky
> titulek), takze pokud na to nekdo ma prava, do toho prosim.
>
> Jakub
>
> On Tue, Dec 17, 2019 at 9:28 PM Aceman444  wrote:
> >
> > Zdravim.
> > Dobry napad.
> > Vzal by som si SK verziu na starost, ak nechce nikto iny.
> > Toto ma irituje a dost novacikom som uz o tom pisal v komentaroch.
> >
> > Za CR prosim dohovorte tomuto borcovi: 
> > https://www.openstreetmap.org/user/Miki%20B/history
> > Dakujem
> >
> > Dňa utorok, 17. decembra 2019 15:08:48 UTC+1 Tom Ka napísal(a):
> >>
> >> Ahoj,
> >>
> >> ve Weekly jsem narazil na zmínku o wiki stránce s radami pro dobré
> >> komentáře pro sady změn, která chybí CZ i SK:
> >>
> >> https://wiki.openstreetmap.org/wiki/Good_changeset_comments
> >>
> >> Tak pokud se někdo bude chtít realizovat, tohle by mohlo být užitečné.
> >>
> >> Bye tom.k
> >
> > --
> > Túto správu ste dostali, pretože v Skupinách Google ste odberateľom skupiny 
> > "Openstreetmap Slovakia".
> > V prípade, že chcete zrušiť odber tejto skupiny a prestať od nej prijímať 
> > e-maily, zaš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/c3e8c456-5953-40b8-80df-23bf45e16076%40googlegroups.com.
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

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

Re: [Talk-us] confusing state of USFS trail names in Oregon

2019-12-19 Per discussione Tod Fitch

In my area there are variations on the Forest Service signs as well (“Ice House 
Canyon Trail” vs “Icehouse Canyon Trail” and “Chiquito Trail” vs “Chiquita 
Trail” are two examples that come to mind). I suspect some of the variations 
are due to changes in spelling, etc. over time so the older signs don’t match 
the newer signs.

The Forest Service is supposed to maintain an official inventory of trails and 
roads. A copy should be at each District Ranger Station and also at the Forest 
Supervisor’s office and at the Region Offices. However at least in Region 5 
where I am it seems that every Forest is woefully understaffed on the 
recreation side because most of the money nowadays is going into fire. Because 
of that there may not even be a recreation officer you can get in contact with. 
I guess you should go up the line trying first at the district ranger station 
where the trail(s) are located.

In the meantime, I’ve dealt with multiple name variations on my mapping by 
putting the most common name (one with most signs in agreement) as the value 
for the OSM name tag and the less common version under the alt_name tag. 
Fortunately I haven’t run into trails that have more than two variations on 
their names. I guess that if/when I do I’ll also have to figure out how to 
parse semicolon separated options in a value using either Postgresql or Mapnik 
XML when I make my personal maps.

Cheers,
Tod

> On Dec 19, 2019, at 9:47 PM, Dion Dock  wrote:
> 
> I did some mountain biking around Bend, Oregon this summer.  Apparently the 
> Deschutes Ranger District of the US Forest Service can’t decide what to call 
> their trails.  For example, at the Skyliners trailhead, there’s a sign that 
> says
>   SKYLINER TRAIL NO. 28
>   JCT. WOOPS TRAIL NO 50 2 1/2
> 
> One of the USFS maps calls it the Woops trail, 
> https://www.fs.usda.gov/Internet/FSE_DOCUMENTS/fseprd639418.pdf 
> .  And 
> there’s another map that I can’t find that seems to back this one up.
> Their web site calls it the Whoops Trail with no number, 
> https://www.fs.usda.gov/recarea/deschutes/recreation/bicycling/recarea/?recid=38294=24
>  
> .
> 
> There’s similar disagreement about Skyliner Trail vs Skyliners.
> 
> So…is this worth trying to straighten out?  Supposedly the trails all have 
> numbers but I can’t find a reliable source (e.g. nothing else gives Whoops 
> #50).
> 
> thanks,
> -Dion
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

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

[Talk-us] confusing state of USFS trail names in Oregon

2019-12-19 Per discussione Dion Dock

I did some mountain biking around Bend, Oregon this summer.  Apparently the 
Deschutes Ranger District of the US Forest Service can’t decide what to call 
their trails.  For example, at the Skyliners trailhead, there’s a sign that says
SKYLINER TRAIL NO. 28
JCT. WOOPS TRAIL NO 50 2 1/2

One of the USFS maps calls it the Woops trail, 
https://www.fs.usda.gov/Internet/FSE_DOCUMENTS/fseprd639418.pdf 
.  And there’s 
another map that I can’t find that seems to back this one up.
Their web site calls it the Whoops Trail with no number, 
https://www.fs.usda.gov/recarea/deschutes/recreation/bicycling/recarea/?recid=38294=24
 
.

There’s similar disagreement about Skyliner Trail vs Skyliners.

So…is this worth trying to straighten out?  Supposedly the trails all have 
numbers but I can’t find a reliable source (e.g. nothing else gives Whoops #50).

thanks,
-Dion___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] What does WGS84 mean for openstreetmap these days?

Yantisa Akhadi  writes:

> To add more challenges to this issue is imagery offset
> . The value
> can even be varied from tiles to tiles, that we often need to shift the
> object a couple of meters away. In a remote area, where there are no GPS
> traces as a reference, satellite imagery is often the only reference even
> when possibly it was a couple of meters off.

Certainly that is a challenge.  But, once the datum is defined clearly,
then it is work to figure out, but not a question of ambiguity as to
what is desired.

I am unclear on whether most imagery offset issues are due to imagery
being in a datum other than modern WGS84 (and not transformed), or just
due to errors.  In Massachusetts, US, it seems most of the imagery
sources are pretty well aligned.  But this cries out for actualy
checking better!

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

Re: [OSM-talk] What does WGS84 mean for openstreetmap these days?

2019-12-19 Per discussione Yantisa Akhadi

To add more challenges to this issue is imagery offset
. The value
can even be varied from tiles to tiles, that we often need to shift the
object a couple of meters away. In a remote area, where there are no GPS
traces as a reference, satellite imagery is often the only reference even
when possibly it was a couple of meters off.

Best,
Iyan

On Fri, Dec 20, 2019 at 12:59 AM Greg Troxel  wrote:

> "Jóhannes Birgir Jensson"  writes:
>
> > I don't think we can or will be providing accuracy up to cm when most
> > of the stuff we map from our chairs is off by a meter or two anyways -
> > the beauty is that it doesn't matter for 99,99% of users. If a
> > centimeter matters then we are probably dealing with legal matters and
> > there OSM makes it quite clear it is not suitable for such.
>
> My actual proposal, as opposed to the things I pointed out I wasn't
> proposing, is about removing the ~2m uncertainty that exists from our
> current definition.
>
> As for cm level, OSM does not have accuracy specifications and won't.
> Some people like to be accurate, and others like to add lots of detailed
> tags.  Between us we have great map.  I don't agree that anybody who is
> trying to be more accurate is necessarily concerned with something that
> is "legal".  I would expect many people would like to see better than 2m
> accuracy.
>
> Certainly cm-level is very difficult, and I see that as being pretty far
> out in the future.
>
> You didn't comment on the notion of defuzzing the reference to WGS84, so
> I'll assume you are ok with that.
>
> > Also regarding the accuracy, as another fast moving country Iceland is
> > actually splitting in the middle and so it edges west and east and
> > south as well, depending on where you are in the country. We've had 3
> > official national datums now, ISN93, ISN2004 and ISN2016 (helpfully
> > naming them after years). The fact is that pretty much everything is
> > still running in ISN93, ISN2004 saw very little uptake and ISN2016 has
> > started very slowly.
> >
> > So for Iceland we do know that we are never going to achieve a
> > centimeter accuracy, pretty much ever, and don't expect a free people
> > sourced geographical database to reach it.
>
> Interesting about the datum history.  But this is the cm strawman I
> wasn't talking about, not the 2m issue.
>
> I would not be surprised if in 20 years OSM had some approach to
> coordinates of crust-fixed points.
>
> ___
> 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-it] [talk-it] tagging accesso bici in Aree Pedonali



sent from a phone

> On 19. Dec 2019, at 18:08, Volker Schmidt  wrote:
> 
> Non è così ovvio a me. Di tutto quello che so l'accesso in bici a una zona 
> pedonale (senza cartelli aggiuntivi) è uguale all'accesso a una ciclopedonale 
> condivisa (che convenzionalmente viene taggata con foot=designated)


forse è sbagliato? Per segregated=yes è giusto, ma per segregated=no potrebbe 
avere più senso un bicycle=yes
che ne dite?


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

Re: [Talk-it] [talk-it] tagging accesso bici in Aree Pedonali

sent from a phone

> On 19. Dec 2019, at 17:40, Fabrizio  wrote:
> 
> C'è anche un dibattito sulla possibilità di attraversare le strisce pedonali 
> in sella alla bici, dalle varie norme sembrerebbe possibile farlo cioè è 
> tollerato in caso non ci siano troppi pedoni ad attraversare, cioè se non 
> arrechi intralcio ai pedoni, ad esempio sei solo ad attraversare lo puoi fare 
> in sella alla bici, confermi? 

io sconsiglio a tutti di farlo. Quando stavo ancora a Berlino è morta la 
ragazza di un amico così: attraversando in bici sulle strisce, alle 10 di 
mattina (la colpa era suo perché le macchine non si possono aspettare qualcuno 
con la velocità di una bici sulle strisce, è oramai quasi 20 anni fa, ma non 
credo siano cambiate le leggi, e anche se qui la situazione legale potrebbe 
essere diversa, quella reale è più a sfavore di chi attraversa sulle strisce 
direi)

> Ps: a Roma ho visto la municipale applicare multe sul manubrio delle bici 
> dello sharing di Uber jump, perché sul marciapiede, e come targa hanno preso 
> il seriale sul parafango

beato te, io non li vedo quasi mai, e vedo ogni giorno macchine sui marciapiedi 
(nonché in seconda fila, a certi punti fissi ogni giorno e ora, come lo sai 
anche tu. Sarà stata un’azione contro UBER, certo che non è la normalità ;-)
Quindi le bici si devono parcheggiare su strada? Non è che poi gli 
automobilisti si arrabbiano?

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

Re: [Talk-us] Trunk VS primary,

2019-12-19 Per discussione Paul Johnson

On Thu, Dec 19, 2019 at 1:19 PM Martijn van Exel  wrote:

> I actually like your suggestion that highway=trunk does not add much value
> to the U.S. map, Eric.
> We love to add detail / granularity to OSM so much, it can become hard to
> envisage taking some away.
> Not saying we should abolish trunk right here and now, but something I'd
> consider as one outcome.
>

I'd like to see a lot more left up to the data consumer and more regional
values to be widely acceptable.  For example, instead of trying to smash
the entire planet into the UK's prescribed values and trying to come up
with equivalences, use the terminology each country uses.  So, for example,
in the US, instead of motorway, trunk, primary, secondary, tertiary,
perhaps something more like freeway, expressway, major/minor_principal
(just having this would fix a *lot* of problems with Texas and Missouri and
their extensive secondary systems), major/minor_collector...the US just has
a way more complex view of how highways work.

Or at least some more serious consideration given to the proposal at
https://wiki.openstreetmap.org/wiki/User:UltimateRiff/HFCS (but perhaps
with "other principal arterials" as primary and a new "highway=quartinary".

Much like moving route refs to highway relations (freeing the ref=* tag on
highways for situations where the road and the route have different refs),
leaving the mental gymnastics up to an algorithm and leaving less confusion
to the mapper is getting to be long overdue.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

2019-12-19 Per discussione stevea

I believe Nuno HAS "reacted positively" by his frequent and constructive 
criticism of what he has seen taking place by third parties who use OSM data 
without proper attribution.  I'd have to check, but it seems he has been doing 
this for the better part of a year (maybe longer).

While I don't wish to diminish the light-hearted, holiday-spirited suggestion 
Pierre makes, I can't help but feel it detracts from the seriousness of the 
concerns expressed by Nuno.  I don't think that was Pierre's intent, but it 
could be easy to misinterpret his comments that way.

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

Re: [OSM-legal-talk] use OSM data to select proprietary data

sent from a phone

> On 20. Dec 2019, at 00:16, Kathleen Lu via legal-talk 
>  wrote:
> 
> And that is for extracting the entirety of each feature. The Geocoding 
> Guideline states: "Furthermore, if only names are provided in Geocoding 
> Results from OSM -- in particular, latitude/longitude information from OSM is 
> not included in the Geocoding Results -- a collection of such results is not 
> a substantial extract."

it should be noted that in the case at hand the intention was to create a new 
database with translated/adapted OpenStreetMap data. The guideline says: 
“ Since individual Geocoding Results are insubstantial extracts, they may be 
stored and used together with other proprietary or third party data without 
having a share-alike impact on such other data, provided the Geocoding Results 
have not been aggregated to create a new database that contains the whole or a 
substantial part of the OSM database.
If Geocoding Results are used to create a new database that contains the whole 
or a substantial part of the contents of the OSM database, this new database 
would be considered a Derivative Database and would trigger share-alike 
obligations under section 4.4.b of the ODbL. ”

the guideline is about individual results, not about aggregations, for which 
the share alike provisions persist. From my interpretation this also implies 
that the attribution requirements persist for individual results, because 
otherwise it would not be clear that you cannot aggregate them. Do you agree?

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

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

2019-12-19 Per discussione Pierre Béland via talk

Hi Nuno, 

How can we react positively suggesting to take care obout OSM attribution ? 
This is an international media and we can benefit by having a bit of fun.

Plus this is Christmas coming soon and we need to think positive !
 You could make tweet to https://twitter.com/BBCTwo   + using OpenStreetMap 
logo image (add @OpenStreetMap as who is on the image) + url link to facebook 
article
 saying
Merry Christmas from the OpenStreetMap community Happy to provide accurate and 
detailed maps to news medias, governnments, research, business, consumers, to 
respond to disasters, etc.  Dont forget - Our New Year Best Wishes to have more 
impact - OpenStreetMap Contributors attribution :)
Then you could invite OSM contributors on the discussion lists to make it Viral 
by responding !
To show OSM diversity, I would be pleased to respond to the tweet.

Bonne année, Pierre Béland, du Québec, Canada, fier de supporter OpenStreetMap.

;)
 
Pierre 
 

Le jeudi 19 décembre 2019 18 h 16 min 44 s UTC−5, Nuno Caldeira 
 a écrit :  
 
 here's another lovely example from BBC TWO using Strava (i can spot the Mapbox 
logo, not the reasonable calculated ©OpenStreetMap contributors). glad BBC 
attributed Google properly. they probably aren't aware it's OpenStreetMap, if 
they can't read the attribution on 
Stravahttps://www.facebook.com/413132078795966/posts/2468472903261863/

On Fri, 1 Nov 2019, 18:59 Nuno Caldeira,  wrote:



On Fri, 1 Nov 2019, 18:05 Simon Poole,  wrote:
 
The fair use point just turned up to illustrate that there are limits on what 
we can expect copyright to do for us (aka the tweets from private individuals 
showing a map excerpt that Nuno pointed to) and there is no point in getting 
upset over that there are such limitations. 

actually Simon those prints indivuals share on social media is sent to their 
emails by the company (as someone pointed after you writing). Strava sends 
emails of OSM basemap to their users without attribution. I been testing Strava 
app today and had a couple of laughts TB. tYhere's even more interesting stuff 
we should take notice when doing the attribution guidance. they use Google maps 
on their android app, the routes they display clearly isn't from their users 
(it's not GPS traces as it is impossible to have no overlaping traces on 
mountain regions). I'm sure these routes are from OSM and I'm gathering 
evidence from my contributions that this is OSM data. I will get back to it 
when I get home and record a video with clear evidence that it is impossible to 
be their users GPS trace or Google Maps (as they do not have data in that 
regions). That could only come from OSM and I'm sure as I added that data and 
weekly monitor the editing and their suggested routes sometimes overlap the 
same route as it displayed different versions of OSM data during the years. 


___
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-us] Trunk VS primary,

2019-12-19 Per discussione Paul Johnson

On Thu, Dec 19, 2019 at 5:13 AM Mike N  wrote:

> On 12/17/2019 10:19 PM, Evin Fairchild wrote:
> > some US routes are more important than others and lumping them all as
> > primary doesn???t make any sense;
>
> The arguments here about relative importance of parallel routes makes
> sense.
>
>Some massive changes such as in
> https://www.openstreetmap.org/changeset/78620805 are raising roads which
> have no other major choices, but are apparently just because they are
> the most important.
>

This smashing everything to the highest possible value I would generally
consider to be an undiscussed and problematic mechanical edit.  Going with
the lowest level that fits feels a bit more correct (think "minimum
effective dose" from medicine, for example), does give routers more
information where there's lots of routes available, and humans more of an
idea what kind of road they're going to encounter at a glance.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-legal-talk] use OSM data to select proprietary data

sent from a phone

> On 20. Dec 2019, at 00:16, Kathleen Lu via legal-talk 
>  wrote:
> 
> This is not what the Substantial Guideline says. It says that fewer than 100 
> features is "not Substantial". It also gives as an example "More that 100 
> Features only if the extraction is non-systematic and clearly based on your 
> own qualitative criteria for example an extract of all the the locations of 
> restaurants you have visited for a personal map to share with friends or use 
> the locations of a selection of historic buildings as an adjunct in a book 
> you are writing, we would regard that as non Substantial."

If I recall correctly there is no definition what a feature is. Nobody has yet 
commented how they would interpret this for a border: is it about the border 
way or about the individual border points from which the border is made of? 

100 features may be a reasonable limit for point features, but for complex ways 
and relations, already very few (maybe even a single one) may be substantial?

Kathleen, I would be interested in your thoughts what a feature is in the 
context of ways.

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

Re: [Talk-us] [Imports] Preliminary Import/Organized Mapping Effort Idea

2019-12-19 Per discussione Paul Johnson

On Thu, Dec 19, 2019 at 3:03 PM Mike Thompson  wrote:

> > I've avoided BIA because their data doesn't seem accurate
> We have gotten some additional feedback off list also suggesting that the
> BIA data may not be as accurate as some other sources.  Perhaps we should
> create a wiki page listing every reservation, its boundary status in OSM,
> and the known sources of data.  Mappers can then "sign up" to work on
> individual reservation boundaries (by adding their name to the wiki page),
> manually comparing the various sources, researching the most correct
> representation, and of course editing OSM to reflect their findings
> just thinking out loud here.--
>

I'm feeling this a lot more than the MapRoulette idea.  Especially if we
can get local participants involved.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Orthos: mise à jour 2018 sur de nombreux départements

2019-12-19 Per discussione Vincent Privat

J'ai beaucoup de retard pour la mise à jour côté JOSM...
Christian, est-ce que tu listes toutes les orthos que tu as mises à dispo
quelque part ? Genre sur le wiki ? Actuellement j'ai conservé les traces
avec des mails, tweets, etc.  je suis quasiment sûr d'en oublier avec ça.

Le jeu. 19 déc. 2019 à 16:52, Christian Quest  a
écrit :

> Elle n'est peut être pas dans les presets... il faut dire que c'est une
> couche composite, pas simple à gérer pour l'attribution !
>
> Pour info, nouveaux départements en version 2018: 02 59 60 62 80
>
> Certains sont dispo pour la première fois (02/60/80).
>
>
> Le mer. 18 déc. 2019 à 18:22, David Crochet  a
> écrit :
>
>> Bonjour
>>
>> Le 17/12/2019 à 12:14, Christian Quest a écrit :
>> > - tous_fr : qui est combinaisons de toutes les orthos, en priorisant
>> > la date puis la résolution
>>
>>
>> Je ne le trouve pas disponible dans JOSM, il faut le rajouter à la main ?
>>
>> Cordialement
>>
>> --
>> David Crochet
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Christian Quest - OpenStreetMap France
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-legal-talk] use OSM data to select proprietary data

2019-12-19 Per discussione Kathleen Lu via legal-talk

>
> “substantial” does not mean it has to be a certain percentage of the whole
> db, you can see this from the substantial guideline, which has fixed limits
> that are not growing with the db. “substantial” means it’s more than one or
> two features (OpenStreetMap-Foundation has declared they see a total of 100
> features as substantial, although it is not completely clear what a feature
> is, for example you could go to an extreme point of view and see the whole
> border of Germany as a single feature (I am not) while a more credible
> interpretation would see every border point as a feature, so that the
> border of Germany would be thousands of features).
>
> This is not what the Substantial Guideline says. It says that fewer than
100 features is "not Substantial". It also gives as an example "More that
100 Features only if the extraction is non-systematic and clearly based on
your own qualitative criteria for example an extract of all the the
locations of restaurants you have visited for a personal map to share with
friends or use the locations of a selection of historic buildings as an
adjunct in a book you are writing, we would regard that as non
Substantial." BTW, a list of flats/houses for sale in the current time
period is not too far off from these examples.
And that is for extracting the entirety of each feature. The Geocoding
Guideline states: "Furthermore, if only names are provided in Geocoding
Results from OSM -- in particular, latitude/longitude information from OSM
is not included in the Geocoding Results -- a collection of such results is
not a substantial extract." There's no 100 feature limit at all for
geocoding.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

2019-12-19 Per discussione Nuno Caldeira

here's another lovely example from BBC TWO using Strava (i can spot the
Mapbox logo, not the reasonable calculated ©OpenStreetMap contributors).
glad BBC attributed Google properly. they probably aren't aware it's
OpenStreetMap, if they can't read the attribution on Strava
https://www.facebook.com/413132078795966/posts/2468472903261863/

On Fri, 1 Nov 2019, 18:59 Nuno Caldeira, 
wrote:

>
>
> On Fri, 1 Nov 2019, 18:05 Simon Poole,  wrote:
>
>> The fair use point just turned up to illustrate that there are limits on
>> what we can expect copyright to do for us (aka the tweets from private
>> individuals showing a map excerpt that Nuno pointed to) and there is no
>> point in getting upset over that there are such limitations.
>>
> actually Simon those prints indivuals share on social media is sent to
> their emails by the company (as someone pointed after you writing). Strava
> sends emails of OSM basemap to their users without attribution.
> I been testing Strava app today and had a couple of laughts TB. tYhere's
> even more interesting stuff we should take notice when doing the
> attribution guidance. they use Google maps on their android app, the routes
> they display clearly isn't from their users (it's not GPS traces as it is
> impossible to have no overlaping traces on mountain regions). I'm sure
> these routes are from OSM and I'm gathering evidence from my contributions
> that this is OSM data. I will get back to it when I get home and record a
> video with clear evidence that it is impossible to be their users GPS trace
> or Google Maps (as they do not have data in that regions). That could only
> come from OSM and I'm sure as I added that data and weekly monitor the
> editing and their suggested routes sometimes overlap the same route as it
> displayed different versions of OSM data during the years.
>
>>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Osm su Android

2019-12-19 Per discussione Francesco Ansanelli

Ciao!

Si... Basta aprire e chiudere i livelli mappa.
È un problema che riscontro anche io con Chrome.
Francesco

Il gio 19 dic 2019, 23:35  ha scritto:

> Segnalo un problema che riscontro su Android :
> il sito Osm normalmente si vede bene ma visualizzando le caratteristiche
> di un oggetto o inserendo un segnaposto, allora la mappa si dimezza e su
> metà di essa appare una zona grigia, a vari zoom, che nasconde il sito di
> interesse.
> Succede anche a voi?
> Come si risolve?
> Lorenzo Pesci
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] Osm su Android

2019-12-19 Per discussione Lorenzops

Segnalo un problema che riscontro su Android :il sito Osm normalmente si vede bene ma visualizzando le caratteristiche di un oggetto o inserendo un segnaposto, allora la mappa si dimezza e su metà di essa appare una zona grigia, a vari zoom, che nasconde il sito di interesse.Succede anche a voi?Come si risolve?Lorenzo Pesci ___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Nommage/Numérotation hameaux

Le 19.12.19 à 22:43, Christian Rogel a écrit :
>> Le 19 déc. 2019 à 15:15, marc marc a écrit :
>> ce n'est en rien plus simple d'avoir un associatedStreet
>> version Christian R., supporté que par lui-même.
>> cela rendrait juste les données utilisables par tous sauf l'humain.

> La nécessité d’utiliser place pour une adresse serait liée au fait d’utiliser 
> des relations ?

non, c'est lié à :
addr:street est lié au highway=* du même nom
addr:place est lié au place=* du même nom
il n'y a aucune relation dans la base osm pour ces 2 tags, le lien se
fait avec "cet objet est sémantiquement lié à cet objet"

> pour moi, il n’y a que des noms de voie
alors pour toi, met un name sur le(s) highway=* du place
et utilise addr:street pour les addresses.
cela ne correspond pas à la réalité du terrain
mais cela serra au moins cohérent avec ton dogme et cela fonctionnera
parfaitement dans les différents outils et éditeurs.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Fw: Appeal for Help - Amending a Route Relation - NCN Route 51

2019-12-19 Per discussione Warin


On 20/12/19 00:54, Peter Neale via Talk-GB wrote:
Many thanks to @Richard Fairhurst, @Warin and @ Paul Berry for their 
encouragement and help.  I will have a go at making the amendments 
using the iD Editor.


I'm not sure how soon that will happen, though, as I hear that 
Christmas is coming and Grandads like me are meant to spend time with 
their families, not on the computer.


Before I start, I have one more question:

@Richard Fairhurst said, "It's more important that the route is 
unambiguous,  i.e. the member ways all join to form a single route 
without unnecessary branches and loops."


However, the Sustrans map shows some dead-end branches (presumably to 
link into other infrastructure, such as roads and other cyclepaths).  
There are 2 that are relevant here; one is marked on the ground 
(probably because it was part of the old route), but the other is 
not.  I do not propose to include the unmarked one, but what about the 
one that is marked?  Should I include it, or not?




Some discussion on the tagging list on this... a read of
https://wiki.openstreetmap.org/wiki/Proposed_features/hiking_trail_relation_roles

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

Re: [OSM-talk-fr] Nommage/Numérotation hameaux

2019-12-19 Per discussione Christian Rogel



> Le 19 déc. 2019 à 15:15, marc marc  a écrit :
>> Le plus simple est de voir tout nom donné comme officiel, venant ou non d’un 
>> nom de lieu que comme il a été voulu, un nom de voie.
> ce n'est en rien plus simple d'avoir un associatedStreet
> version Christian R., supporté que par lui-même.
> cela rendrait juste les données utilisables par tous sauf l'humain.
> 
> Si on voulait progresser sur le sujet, il faudrait à mon avis commencer
> par améliorer l'associatedStreet actuel dans les éditeurs, avant
> d'envisager une proposition hypothétiquement acceptée regroupant
> associatedStreet Street et les addr:place.

La nécessité d’utiliser place pour une adresse serait liée au fait d’utiliser 
des relations ? N’utilisant pas, par principe, associatedstreet, pour moi, il 
n’y a que des noms de voie, dont la syntaxe ou l’historique n’a pas 
d’importance, ni plus, ni moins que ce que l’on retient de l’arrêté municipal : 
un odonyme a été créé. Le cadastre et FANTOIR sont des sources secondaires 
sujettes à erreurs et fausses interprétations, souvent reproduites ensuite par 
la mairie.

Christian R.

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

[Talk-de] 36C3 [Was: Weihnachtskarten 2019]

2019-12-19 Per discussione Hartmut Holzgraefe


On 19.12.19 19:29, Michael Reichert wrote:

Hallo,

vielen Dank für das rege Interesse. Wir haben die Karten aller 34
Empfänger heute gedruckt und zur Post gebracht.


für 36C3 Besucher gibt es dann auch in Leipzig wieder die Chance
auf gedruckte Karten, dieses Jahr am OSM-Schiff im OpenInfrastructure
Bereich ...

(Wenn der Drucker nicht wieder rumzickt wie in Heidelberg. Mein
Erstatzteuldepot habe ich dementsprechend aufgerüstet)

--
hartmut


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

Re: [Talk-us] [Imports] Preliminary Import/Organized Mapping Effort Idea

2019-12-19 Per discussione Mike Thompson

Clifford,

Thanks for your feedback.

> I've avoided BIA because their data doesn't seem accurate
We have gotten some additional feedback off list also suggesting that the
BIA data may not be as accurate as some other sources.  Perhaps we should
create a wiki page listing every reservation, its boundary status in OSM,
and the known sources of data.  Mappers can then "sign up" to work on
individual reservation boundaries (by adding their name to the wiki page),
manually comparing the various sources, researching the most correct
representation, and of course editing OSM to reflect their findings
just thinking out loud here.

Mike

On Wed, Dec 18, 2019 at 10:10 AM Clifford Snow 
wrote:

> Mike,
> Thanks to you, David and Paul for taking the initiative to mapping Natiive
> American Reservations. On and off for the last few years I've been
> attempting to reservations mapped in Washington State. My first choice for
> boundary information has always been from the reservation then the state.
> I've avoided BIA because their data doesn't seem accurate, at least at the
> time when I first started adding reservations. I look forward to seeing how
> it compares to the boundaries I added.
>
> I especially applaud your desire to involve Native American youth in the
> project. I have struggled to make any headway getting the tribes involved.
> Related to that I've been asking people I know that work for the tribes
> about adding features in their native language. A number of the tribes
> around me are working hard to ensure their languages not only survives but
> flourishes. I'm hoping with my connections I can partner with the tribe get
> them to actively contribute to OSM using their native language. It is
> something you might also consider doing.
>
> Let me know how I can help,
> Clifford
>
> On Tue, Dec 17, 2019 at 4:35 PM Mike Thompson  wrote:
>
>>
>> Village Earth's Native Land Advocacy Project[1], David Bartecchi[2], Paul
>> Johnson[3], and I[4] are considering an organized effort to improve the
>> boundaries of Native American Reservations in the US.  We have studied the
>> import guidelines on the wiki and will follow those, however, we first
>> wanted to see:
>>
>> 1) If there was any fundamental objection to this idea before even the
>> details are spelled out
>>
>> 2) If anyone is already working on this issue.
>>
>> 3) If anyone would like to join us.
>>
>>
>> We are thinking that our general approach will be:
>>
>> 1) Use data from this source:
>> https://biamaps.doi.gov/dataDownload/index.htmlIt has a compatible
>> license, but will verify and document as part of this process.
>>
>> 2) Somehow allow mappers to "check out" a particular reservation's
>> boundary.  Exact mechanism is TBD.
>>
>> 3) A human mapper will examine each boundary individually
>>
>> 4) Where OSM does not have a corresponding reservation boundary, the
>> mapper will import the boundary into OSM (not sure of the exact mechanics
>> at this time).  If the boundary needs to participate in a boundary
>> relation, that will be handled here. Tag mapping is TBD at this point.
>> Any conflicts with existing OSM features will be addressed in this step.
>>
>> 5) Where OSM has a boundary and it does not match the above source, and
>> it has not been edited by a human mapper, proceed as in 4 above, except
>> only replace geometry and preserve the history of the existing OSM
>> features.
>>
>> 6) Where OSM has a boundary and it does not match our source, but it has
>> been edited by a human mapper, use additional sources, including tribal
>> sources, and county sources, to determine the true boundary and make
>> necessary edits in OSM.  Deference will be given to the edits made by local
>> mappers.
>>
>> To be determined:
>> We are aware of some cases where different government bodies (e.g.
>> Federal Government vs. a state government) dispute the extent of a
>> reservation.
>>
>> Long term we would like to involve Native Americans, particularly youth
>> living on reservations, in adding additional details to OSM about
>> reservations, such as street names, amenities, etc., but we don't envision
>> this as part of this import/organized effort process.
>>
>> We look forward to your initial feedback on this preliminary concept.
>>
>> Mike
>>
>>
>> [1] Village Earth is a 501(c)(3) nonprofit organization that has worked
>> in Indian Country for over 20 years and works closely with the Indian Land
>> Tenure Foundation
>> [2] David works for Village Earth
>> [3] Most people on this list are probably familiar with Paul, a long time
>> contributor to OSM
>> [4] My OSM user name is tekim, I have been mapping in OSM since 2009.
>> ___
>> Imports mailing list
>> impo...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
>>
>
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
>
___
Talk-us mailing list

Re: [OSM-talk-fr] Noms de rue, osmose et bano V2

2019-12-19 Per discussione Eric H. Christensen via Talk-us

Autre type d'erreurs trouvé dans OSM:

- FANTOIR:
1400470712ZRUE MARCEL DASSAULTR 0  00
0001990240   003721   DASSAULT
- OSM (sur le way de type highway, pas sur une relation):
ref:FR:FANTOIR=0712Z0049D

Autrement dit pas de code département/direction/commune, mais le bon code
RIVOLI à 4 chiffres et la bonne clé (0712Z).

Je me demande bien d'où vient le "0049D" qui a été ajouté après et ne
correspond à rien d'autre dans le FANTOIR.

Cela semble provenir d'une source "pré-FANTOIR" tierce (code interne du SIG
d'une commune, ou d'une CCI) ???

Il y a 5 ans le projet BANO n'était pas si avancé, encore moins le
rapprochement FANTOIR. J'ai l'impression que les sources FANTOIR étaient
difficiles à trouver et qu'on travaillait sur des documents dérivés fournis
par des tiers qui utilisaient leur propre codification supplémentaire après
le code RIVOLI.
Hors la dernière modif de ce way date d'il y a plus de 5 ans, faite dans
JOSM avec comme seule source indiquée "survey", est-il possible que les
pseudo-codes FANTOIR figurent sur certains panneaux à Bayeux, ou que le
0049D corresponde à une référence de positionnement d'une cellule de grille
(sur un plan communal ou cadastral) ?

Des contributeurs d'OSM utilisent-ils d'autres sources que le fichier
national de la DGFIP (mis à jour tous les 3 mois, ou la couche "BANO"
proposée dans iD et JOSM) pour trouver les codes FANTOIR ?

Combien de tels références dans OSM ne correspondent à rien? Que faire des
anciennes références FANTOIR obsolètes (notamment les codes "Z"), ne
peut-on pas les repérer (puisqu'en principe il ne devrait rester aucun des
codes "Z" qui n'ont servi que transitoirement pendant le rapprochement par
la DGFIPS de diverses sources basées plus ou moins sur l'ancien système
RIVOLI pas encore unifié.

S'il y a de tels codes restants cela peut compliquer les rapprochements et
les mises à jour ultérieures. Pourtant si on avait au minimum la validation
du format par l'expression rationnelle suivante (qu'on peut encore
raffiner) on peut déjà faire des détections plus rapides d'erreurs qui
"trainent" depuis longtemps.

[out:xml][timeout:500];
nwr["ref:FR:FANTOIR"~"^.{10}$"]["ref:FR:FANTOIR"!~"^[0-9][0-9AB][0-9]{3}[0-9A-Z][0-9]{3}[A-HJ-NPR-Z]$"];
out meta;
>;
out meta qt;


Notes:
- deux expressions car c'est plus rapide, sinon Overpass tombe sur un
débordement mémoire si on utilise le comparateur "!~" directement, car ça
présélectionne des milliards d'objets)
- la première expression rationnelle filtre d'abord les codes à 10
caractères, qui ont donc la bonne longueur attendue, la seconde supprime de
la liste les codes de format valides
- on peut améliorer cette expression pour les codes départements (et
direction)
  * pour les départements 01 à 12, 14 à 19, 2A, 2B, 21 à 58, 60 à 74, 76 à
91, 93 à 95, le code direction est toujours 0, sinon c'est 971 à 976, sont
donc exclus 00,13,20,59,75,92,96,98,99)
  * pour les départements 13,59,92, le code direction ne peut être que 1 ou
2, pour le département 75 il n'est que de 4 à 8.
  * déterminer le code direction permet de valider la lettre-clé mais pas
dans une expression rationnelle où on ne peut que valider  [A-HJ-NPR-Z]
  * les codes commune à 3 chiffres devraient être entre 001 et 899 (en
excluant 000 et 9nn) on peut faire mieux si on connait le plus grand code
commune de chaque département, puis gérer les codes "réellement"
inexistants (les anciens codes existent aussi et restent réservés par
l'INSEE, surtout pour les anciennes communes fusionnées mais pas en fusion
simple: communes déléguées ou associées; l'INSEE pourtant les garde bien
plus longtemps pour le rapprochement statistique sur au moins 10 ans et en
fait bien plus, tant qu'il y a des SIRET valides pour les organisations qui
y ont été déclarées, et des personnes vivantes qui y ont été inscrites dans
l'Etat-Civil pour leur numéro d'identité; les numéros d'état-civil peuvent
durer plus de 120 ans, bien peu de codes sont réellement retirés, et il
arrive aussi que des communes défusionnent; et il y a 120 ans, il y avait
les départements d'Algérie avant la restructuration de l'ancien département
de la Seine qui a réutilisé les codes d'Algérie, en pratique aucun code
INSEE de commune ne peut encore disparaître facilement)

Le jeu. 19 déc. 2019 à 17:16, Philippe Verdy  a écrit :

> Le 3e nom (type 0) n'est pas vraiment bon nom plus: "LOT" est repris du
> deuxième nom (type A) où c'était l'abréviation générique de "lotissement"
> (nature de voie).
> Dans tout ça ça donnerait l'adresse "Voie Lotissement Dona Maria", mais là
> clairement soit c'est "Lotissement Dona Maria", soit "Voir Dona Maria".
> On dirait que l'ajout de "LOT" en préfixe du 2e libellé n'est là que parce
> qu'il faudrait unicité du couple nature_voie+libelle_voie.
>
> On se demande alors la raison d'être de cette séparation des champs
> "nature_voie" et "libelle_voie", qui en fin de compte n'en forment qu'un
> seul indissociable (mais dont la

Re: [Talk-us] Trunk VS primary

2019-12-19 Per discussione stevea

I now reiterate the fundamental struggle in this discussion (which can be 
summed up as "both"):

highway=trunk is another level of granularity (above primary) to describe "high 
performance OR high importance roads" (emphasis mine).  Additionally,

(from the US-specific definition from our wiki):  highway=trunk is a "surface 
expressway:  a relatively high-speed divided road (at least 40 MPH with a 
barrier or median separating each direction of traffic), with a limited amount 
of intersections and driveways; or a major intercity highway."

Similar to "descriptive vs. prescriptive," this semantic "struggle" might be 
described as these two definitions being "relative vs. absolute."

Some people say a gravel road (or even a dirt road, if that dominates, say, in 
a developing country) is important enough to be tagged "trunk," for example in 
Alaska.  That is using "trunk" in its relative sense:  relative as to what is 
also meant by primary, secondary, etc. IN THAT LOCAL/REGIONAL CONTEXT.  Some 
people say "trunk must be divided with a barrier/median and medium-to-higher 
speed..." (or fill in some hand-waving additions).  That is using "trunk" in 
its absolute sense.

"Both."  Yes, both.  I'll say it again, OSM, I doubt it very much, will ever, 
EVER get away from how we now define "trunk" as "both."  Look at our wiki and 
see how there are differing definitions for differing countries and see how we 
define it relatively.  Look at our wiki's text and see how we define it 
absolutely.  Both.

Can we (as humans) and routers (as software) learn to live with this apparent 
dichotomy?  I can.  I believe the rest of us (humans and routers alike) can, 
too.

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

Re: [Talk-us] Trunk VS primary,

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

‐‐‐ Original Message ‐‐‐
On Thursday, December 19, 2019 2:19 PM, Martijn van Exel  wrote:

> I actually like your suggestion that highway=trunk does not add much value to 
> the U.S. map, Eric.
> We love to add detail / granularity to OSM so much, it can become hard to 
> envisage taking some away.
> Not saying we should abolish trunk right here and now, but something I'd 
> consider as one outcome.

It does seem like there is a lot of arbitrary conditions separating some of 
these road types.  It would be nice to have solid reasoning for tagging a 
roadway a certain way instead of how "important" it is.

The routing engine should be able to take into account the road surface, number 
of stop lights, and other factors into consideration if there are multiple 
routes of similar highways that are "important", IMO.  Any idea why trunk was 
established in the first place?

--Sparks
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsFcBAEBCAAGBQJd+93IAAoJEIB2q94CS7PRz34QALpd+bUfV2YniWX9qVtb
nzFxEsdPp8dzt/s4HewS93wDtSrVKM7rtuPLTnDetFrI4Yl5bZ3JfkrDRfDR
KkxYbgU1/Fjrjz/MCJ+aoDh0SwKVwSUDMpX9nJtNxNHfaqjxu6Z86eKLcBX1
ceAUnTMoUQfDnWSH3TUPadQOkwij1r0Ja2EreKuSJwMk+geGs8qlVU0sNf0x
3KooDARDgIvTbul1344kt0QceK42py0P4RjqRsFJnjg9cCGa07BD1pb6R+qk
2xWL9Q0cCnbF/mhCQ1LoQvIzdgQl/4jvccQ7vyBwgkqbg1f63X0dDbQMPT6F
mRtZ6almPUg0XP0jO33s7JKruMuO4OaJhMYY7h4N1EscjiDcm1zXzz5OCsXP
2QEKnSDkP6h0DAGL58A3rmI0c8z9qAUT+kVrLU1nJDb4WhUsNcpch87Rswi3
w9VFKBEAYVuD9EwJN37e8xG21SO289alvb1hVGzI914aovSbOElluDrQ3F8p
yyD8d7m2wEebEjNzaKRHXVTC1bsiBzruZiUZt9K69Cxv5m3YJHW7giPagKEW
V/o6kwBJOrXnwtF9U/AZCA+EhPF7Myb2tfMdPsWzr0kq4Yy0vfb9V7Y7Ldnw
MlTc8QtIRUfjejWGV2mXDPxghGQ50YGnipG4NjVuSOhhs/yO3ZDOB0pDorxF
VtwA
=uMfV
-END PGP SIGNATURE-


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

Re: [Talk-GB] What is a Department Store

2019-12-19 Per discussione Stuart Reynolds

Hi Phil,

In my opinion, where you pay for it is irrelevant. It is a store with multiple 
departments, and as such is a department store. You mentioned Debenhams as an 
example of a department store - it still exists, of course, and it is still a 
department store, but you can pay at any till.

On the flip side, no-one would ever describe Foyles as anything other than a 
bookshop. However, back in the day it was very much stuck in the 70s itself. 
You couldn’t pay for books from different departments, instead you had go 
around the shop, choose your books, leave them at their departments, get a set 
of bills, go to the (admittedly single) till, pay, and then go back and pick up 
your books from the departments you’d left them in. It was surreal. But aside 
from that trip down memory lane, you were effectively billed from each 
department and couldn’t get billed out of department, which sort of meets your 
definition of a department store. But it wasn’t one - it was (and still is) a 
bookshop.

Cheers
Stuart

> On 19 Dec 2019, at 19:12, Philip Barnes  wrote:
> 
> A simple question, but probably a complex answer.
> 
> Growing up a department store was divided up into a series of
> departments, each operated almost as separate shops with their own
> staff, own till and you paid for what you bought before you moved on to
> the next department.
> 
> The obvious example is Harrods, but Grace Brothers (1) was a familiar
> example, along with Rackhams, Debenhams.
> 
> The key feature in my mind is that each department is that you paid in
> each shop, you couldn't buy a pair of shoes and pay for them in the
> record department. The big thing that kept me out of such places was
> the perfume department which always seemed to be just inside the main
> door to overpower and drive me back out.
> 
> In OSM we are using department store to describe most commonly for
> example M & S. Whilst it does have departments, you take things to a
> single till. Food is still sort of separate, but as far as I am aware
> you can pay for your socks along with your groceries.
> 
> ASDA Home may fit this, but again you pay at a single till area.
> 
> Was taken to TK Maxx today, had never been in before and had always
> assumed it was a clothes shop and had mapped it as such. It sells much
> more than clothes, actually felt like BHS used to. But again you take
> things to a single till. On checking, iD suggests Department Store.
> 
> What do others think?
> 
> Am I stuck in the 70s?
> 
> Phil (trigpoint)
> 
> 
> 
> 
> 
> 1. https://www.youtube.com/watch?v=gTCUuTGNEnI May not be familiar to
> all as it doesn't get the repeats that other series of the era do
> (Dad's Army, On The Buses)
> 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [Talk-us] Trunk VS primary,

2019-12-19 Per discussione Martijn van Exel

I actually like your suggestion that highway=trunk does not add much value
to the U.S. map, Eric.
We love to add detail / granularity to OSM so much, it can become hard to
envisage taking some away.
Not saying we should abolish trunk right here and now, but something I'd
consider as one outcome.
Martijn

On Thu, Dec 19, 2019 at 7:27 AM Eric Ladner  wrote:

> I personally dislike "trunk".  Its definition is vague and leaves a lot to
> interpretation (and argument).  It doesn't really add anything to the
> information on the map, IMO.  A US Highway is a US Highway regardless of
> how much traffic it carries or how many stoplights it has.
>
> Maybe if the definition of "trunk" was solidified to something more
> specific, it would have a more valuable use case.
>
> On Thu, Dec 19, 2019 at 5:15 AM Mike N  wrote:
>
>> On 12/17/2019 10:19 PM, Evin Fairchild wrote:
>> > some US routes are more important than others and lumping them all as
>> > primary doesn???t make any sense;
>>
>> The arguments here about relative importance of parallel routes makes
>> sense.
>>
>>Some massive changes such as in
>> https://www.openstreetmap.org/changeset/78620805 are raising roads which
>> have no other major choices, but are apparently just because they are
>> the most important.
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> --
> Eric Ladner
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-GB] What is a Department Store

2019-12-19 Per discussione Philip Barnes

A simple question, but probably a complex answer.

Growing up a department store was divided up into a series of
departments, each operated almost as separate shops with their own
staff, own till and you paid for what you bought before you moved on to
the next department.

The obvious example is Harrods, but Grace Brothers (1) was a familiar
example, along with Rackhams, Debenhams.

The key feature in my mind is that each department is that you paid in
each shop, you couldn't buy a pair of shoes and pay for them in the
record department. The big thing that kept me out of such places was
the perfume department which always seemed to be just inside the main
door to overpower and drive me back out.

In OSM we are using department store to describe most commonly for
example M & S. Whilst it does have departments, you take things to a
single till. Food is still sort of separate, but as far as I am aware
you can pay for your socks along with your groceries.

ASDA Home may fit this, but again you pay at a single till area.

Was taken to TK Maxx today, had never been in before and had always
assumed it was a clothes shop and had mapped it as such. It sells much
more than clothes, actually felt like BHS used to. But again you take
things to a single till. On checking, iD suggests Department Store.

What do others think?

Am I stuck in the 70s?

Phil (trigpoint)





1. https://www.youtube.com/watch?v=gTCUuTGNEnI May not be familiar to
all as it doesn't get the repeats that other series of the era do
(Dad's Army, On The Buses)


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

Re: [Talk-de] Weihnachtskarten 2019

2019-12-19 Per discussione Michael Reichert

Hallo,

vielen Dank für das rege Interesse. Wir haben die Karten aller 34
Empfänger heute gedruckt und zur Post gebracht.

Viele Grüße, frohe Weihnachten und einen guten Rutsch ins neue Jahr

Michael von der Geofabrik



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

Re: [Talk-GB] No Through Road Ahead

2019-12-19 Per discussione Dave F via Talk-GB

The advice to tag the tight corner is correct. There's no requirement to 
tag the whole road as any router/sat nav worth their salt should search 
well ahead for any such restrictions.


Are there chevron signs at the corner?

You can always map the actual sign, but personally I don't bother as 
I've yet to see how any routers can make use of it.


Cheers
DaveF


On 19/12/2019 14:06, Martin Wynne wrote:

How to tag this road?

 https://goo.gl/maps/B4kUxoR83ej9JXWQ8

There is no actual barrier, just a very sharp corner.

Thanks.

Martin.

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



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

Re: [OSM-talk] What does WGS84 mean for openstreetmap these days?

"Jóhannes Birgir Jensson"  writes:

> I don't think we can or will be providing accuracy up to cm when most
> of the stuff we map from our chairs is off by a meter or two anyways -
> the beauty is that it doesn't matter for 99,99% of users. If a
> centimeter matters then we are probably dealing with legal matters and
> there OSM makes it quite clear it is not suitable for such.

My actual proposal, as opposed to the things I pointed out I wasn't
proposing, is about removing the ~2m uncertainty that exists from our
current definition.

As for cm level, OSM does not have accuracy specifications and won't.
Some people like to be accurate, and others like to add lots of detailed
tags.  Between us we have great map.  I don't agree that anybody who is
trying to be more accurate is necessarily concerned with something that
is "legal".  I would expect many people would like to see better than 2m
accuracy.

Certainly cm-level is very difficult, and I see that as being pretty far
out in the future.

You didn't comment on the notion of defuzzing the reference to WGS84, so
I'll assume you are ok with that.

> Also regarding the accuracy, as another fast moving country Iceland is
> actually splitting in the middle and so it edges west and east and
> south as well, depending on where you are in the country. We've had 3
> official national datums now, ISN93, ISN2004 and ISN2016 (helpfully
> naming them after years). The fact is that pretty much everything is
> still running in ISN93, ISN2004 saw very little uptake and ISN2016 has
> started very slowly.
>
> So for Iceland we do know that we are never going to achieve a
> centimeter accuracy, pretty much ever, and don't expect a free people
> sourced geographical database to reach it.

Interesting about the datum history.  But this is the cm strawman I
wasn't talking about, not the 2m issue.

I would not be surprised if in 20 years OSM had some approach to
coordinates of crust-fixed points.

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

Re: [OSM-talk] What does WGS84 mean for openstreetmap these days?

2019-12-19 Per discussione Oisin Herriott (Insight Global Inc) via Talk-us

Simon Poole  writes:

> Thus is a slightly tricky subject and it is not going away.
>
> For another aspect of it see
> https://www.openstreetmap.org/user/StephaneP/diary/390290

Thanks -- I had not seen that.

I would say that to be pedantic, there is a minor error in the post, in
that OSM coordinates are by definition WGS84.  Agreed that when people
add points with coordinates that are in other datums, then the points in
the database have errors.

I am in the process of figuring out how to deal with this, as accurate
locations in my state basically come from using the state's reference
network, which gets you NAD83(2011) epoch 2010.0.

> Essentially in some cases we are using imagery that isn't actually using
> WGS84 as if it was (fsvo of WGS84 as you correctly point out) and we
> currently don't actually have a way to correct this . And yes while
> continental shift is for most countries smaller than all the other ones
> when adding geometry, for Australia this not necessarily true.

That's true for how people with editors generate coordinates.  It seems
quite possible to adjust imagery to WGS(G1762) in editors, and arguably
that should happen.  I wonder though how often imagery is sufficiently
accurate in some national datum that this matters.  I suspect it's more
and more often.

In my message, was really trying to deal with the issue that by saying
"WGS84" instead of "WGS84(current realization)", OSM has a built-in
uncertainty of about 2m before we even start talking about where data
came from.  That seems easy to take off the table with zero workflow
changes.  At least then there will be a clear definition of what's
intended.

Actually changing the notions is much more difficult and I was trying to
separate the easy step from the harder ones.

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

[Talk-us] [Imports] Preliminary Import/Organized Mapping Effort Idea

Hi all,

Looking to get more people/groups involved in OSM is always a challenge. One 
place I might start would be to reach out to those mappers who have last edited 
the current boundaries and ask them their thoughts on this project. If you are 
using JOSM editor you can use ‘Ctrl + h’ to find the history of an object and 
reach out to the previous editor of that feature via OSM.

The Openstreetmap Contributors map tool is 
also a way to see who is very active in an area, and could provide more local 
mappers of various experience that you could reach out to individually to for 
their input on local project proposals to get the community involved.

This looks like a great project- Best of luck!

Oisin

Sent from Mail for Windows 10

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

Re: [Talk-it] [talk-it] tagging accesso bici in Aree Pedonali

2019-12-19 Per discussione Volker Schmidt

On Thu, 19 Dec 2019 at 17:40, Fabrizio  wrote:

> Molto interessante questa discussione! Spero che ne possa uscire una bella
> pagina wiki dove si cerca di riassumere i vari casi per l'applicazione del
> cds alle bici, con i vari tags.
>
Io ho da un po' di tempo questa bozza sul wiki
, mi
manca il tempo di portarlo avanti.
Era pensato per mettere man mano in un unico posto, tutte queste cose delle
quali parliamo anche in questo thread.

Anche io concorderi per bicycle=yes nelle aree pedonali e non designated.
>
Non è così ovvio a me. Di tutto quello che so l'accesso in bici a una zona
pedonale (senza cartelli aggiuntivi) è uguale all'accesso a una
ciclopedonale condivisa (che convenzionalmente viene taggata con
foot=designated)
La vera ragione per la confusione è la segnaletica illogica in Italia.


> C'è anche un dibattito sulla possibilità di attraversare le strisce
> pedonali in sella alla bici, dalle varie norme sembrerebbe possibile farlo
> cioè è tollerato in caso non ci siano troppi pedoni ad attraversare, cioè
> se non arrechi intralcio ai pedoni, ad esempio sei solo ad attraversare lo
> puoi fare in sella alla bici, confermi?
>
Si, sembra essere proprio così. Anche questo cade nella categoria
"illogicità della legge" in Italia.
L'Italia è l'unico paese, penso, che ha creato un cartello appositamente
per attraversamenti ciclabili. Ma ci sono attraversamenti dove puoi
traversare legalmente in sella per legge e dove questo cartello non c'è e
l'automobilista non viene avvertito di questo fatto.
Io, nel mio piccolo, per proteggere i ciclisti, ho mappato tutti quei
attraversamenti, dove l'automobilista vede un attraversamento solo
"pedonale" (cioè solo strisce pedonali e solo cartello "attraversamento
pedonale") come pedonale anche se, il ciclista ha tutto il diritto di
attraversare in sella. Non mi sento di fare diversamente per non mettere a
rischio i ciclisti.

Ps: a Roma ho visto la municipale applicare multe sul manubrio delle bici
> dello sharing di Uber jump, perché sul marciapiede, e come targa hanno
> preso il seriale sul parafango
>
Accetterei, se facessero la stessa cosa per tutte le auto e moto
parcheggiate su marciapiedi, corsie ciclabili e attraversamenti ...
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Rendu transport routier...

Bonjour,

Le 19.12.19 à 17:31, laurent-38 a écrit :
> Voici une question « tagging » : lorsque la limitation est associée au
> panneau d’entrée en agglomération (genre interdit aux +3.5T sauf desserte),
> est-il suffisant de rajouter la limitation en question sur les segments en
> entrée d’agglomération, ou faut-il la mettre sur toutes les voies
> (principales) de l’agglomération ?

le mettre sur toutes les highway d'entrée, fonctionnera :)
mais jusqu'à ce qu'une nouvelle entrée fasse son apparition

c'est le même probblème que pour la vitesse agglomération par défaut :
pour le moment il faut la mettre sur tous les highway.

l'idéal est de créer une relation type=default pour la définir sur toute
l'agglomération mais aucun routage n'est connu pour l'utiliser,
en partie parce qu'il manque sans doute qlq détails pour la faire voter
(dont une simplification d'une série de ces relations, surtout au niveau
hierarchie)

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

Re: [Talk-it] [talk-it] tagging accesso bici in Aree Pedonali

2019-12-19 Per discussione Fabrizio

Molto interessante questa discussione! Spero che ne possa uscire una bella
pagina wiki dove si cerca di riassumere i vari casi per l'applicazione del
cds alle bici, con i vari tags. Anche io concorderi per bicycle=yes nelle
aree pedonali e non designated. C'è anche un dibattito sulla possibilità di
attraversare le strisce pedonali in sella alla bici, dalle varie norme
sembrerebbe possibile farlo cioè è tollerato in caso non ci siano troppi
pedoni ad attraversare, cioè se non arrechi intralcio ai pedoni, ad esempio
sei solo ad attraversare lo puoi fare in sella alla bici, confermi?
Ps: a Roma ho visto la municipale applicare multe sul manubrio delle bici
dello sharing di Uber jump, perché sul marciapiede, e come targa hanno
preso il seriale sul parafango

Il gio 19 dic 2019, 13:03  ha scritto:

> Invia le richieste di iscrizione alla lista Talk-it all'indirizzo
> talk-it@openstreetmap.org
>
> Per iscriverti o cancellarti attraverso il web, visita
> https://lists.openstreetmap.org/listinfo/talk-it
> oppure, via email, manda un messaggio con oggetto `help' all'indirizzo
> talk-it-requ...@openstreetmap.org
>
> Puoi contattare la persona che gestisce la lista all'indirizzo
> talk-it-ow...@openstreetmap.org
>
> Se rispondi a questo messaggio, per favore edita la linea dell'oggetto
> in modo che sia più utile di un semplice "Re: Contenuti del digest
> della lista Talk-it..."
> Argomenti del Giorno:
>
>1. Re: [talk-it] tagging accesso bici in Aree Pedonali
>   (francesco gargano)
>2. Re: [talk-it] tagging accesso bici in Aree Pedonali
>   (Volker Schmidt)
>
>
>
> -- Forwarded message --
> From: francesco gargano 
> To: openstreetmap list - italiano 
> Cc:
> Bcc:
> Date: Wed, 18 Dec 2019 21:57:12 +0100
> Subject: Re: [Talk-it] [talk-it] tagging accesso bici in Aree Pedonali
>
>
> Il giorno mer 18 dic 2019 alle ore 12:07 Martin Koppenhoefer <
> dieterdre...@gmail.com> ha scritto:
>
>>
>>
>> sent from a phone
>>
>> > On 18. Dec 2019, at 10:35, Simone Saviolo 
>> wrote:
>> >
>> > Sul divieto di transito invece sono sicuro - ne parlai non molto tempo
>> fa con la polizia municipale. La ZTL è effettivamente un'ordinanza che ogni
>> Comune emette con le sue specificità, ma ognuna di esse dev'essere
>> riportata sulla segnaletica.
>>
>>
>> esatto. Non conosco le statistiche nazionali sul tipo di divieto emesso,
>> ma a Roma le ZTL fanno entrare le bici (cosa mi sembra anche logico, visto
>> che non fanno rumore, non inquinano e non occupano posti macchina,  che
>> sono gli scopi della ZTL di ridurre). Se in altre ZTL le bici sono esclusi
>> potrebbe essere dovuto ad altri scopi, oppure al fatto che nessuno ci ha
>> pensato.
>>
>> Ciao Martin, per un riepilogo della regolamentazione delle vigenti ZTL
> sparse lungo lo stivale italico recentemente [1] il M.I.T. ha redatto un
> [2] elenco dove ha raccolto i comuni con accessi ZTL elettronici.
> A meno di casi "esotici" molto particolari , la circolazione in ZTL è
> consentita ai velocipedi così come ne è consentita la circolazione anche
> nelle "Aree Pedonali".
> Sul tema è intervenuta la [3] pubblicazione ufficiale da parte della
> Direzione generale per la sicurezza stradale - M.I.T.  delle [4]"Linee
> Guida sulla regolamentazione della circolazione stradale e segnaletica
> nelle zone a traffico limitato"
> in cui è ribadito che:
> ''L’Area Pedonale  (AP), che rappresenta un caso particolare di ZTL, in
> cui la limitazione della circolazione riguarda tutte le categorie di
> veicoli a motore, è un’area riservata ai pedoni e quindi interdetta alla
> circolazione dei veicoli, salvo quelli in servizio di emergenza, i
> velocipedi e i veicoli al servizio di persone con limitate o impedite
> capacità motorie, nonché eventuali deroghe per i veicoli ad emissioni zero
> aventi ingombro e velocità tali da poter essere assimilati ai velocipedi.''
>
>
> [1]
> http://www.mit.gov.it/documentazione/elenco-comuni-con-ztl-del-31072019
> [2]
> http://www.mit.gov.it/sites/default/files/media/documentazione/2019-08/elencovarchi_31_07_%202019.pdf
> [3]
> http://www.mit.gov.it/documentazione/linee-guida-zone-traffico-limitato
> [4]
> http://www.mit.gov.it/sites/default/files/media/documentazione/2019-07/Linee_Guida_ZTL_5050_28_giugno_2019.pdf
>
>
>
>
>
> -- Forwarded message --
> From: Volker Schmidt 
> To: openstreetmap list - italiano 
> Cc:
> Bcc:
> Date: Thu, 19 Dec 2019 00:49:10 +0100
> Subject: Re: [Talk-it] [talk-it] tagging accesso bici in Aree Pedonali
> A Padova hanno una soluzione geniale:
> Nella ZTL non possono entrare veicoli salvo: residenti con permesso,
> veicoli elettrici (ma chi devono chiedere permesso in persona con
> documenti), motociclette, motorini, biciclette. Ma i cartelli d'ingresso
> mostrano Divieto per Veicoli e la dicitura "salvo autorizzati" e un numero
> di telefono.
> Poi tutto solo per certi orari che variano tra le sub-ZTL. Poveri
> non-locali o stranieri.
>
> On Wed, 18 Dec

Re: [OSM-talk-fr] Rendu transport routier...

2019-12-19 Per discussione laurent-38

Bonjour,

Voici une question « tagging » : lorsque la limitation est associée au
panneau d’entrée en agglomération (genre interdit aux +3.5T sauf desserte),
est-il suffisant de rajouter la limitation en question sur les segments en
entrée d’agglomération, ou faut-il la mettre sur toutes les voies
(principales) de l’agglomération ?

Cordialement
~~
laurent



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

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

Re: [OSM-talk-fr] Nommage/Numérotation hameaux (Était : Re: Joli noms de rues)

L'ennui c'est que le mot directeur réellement discriminant est le dernier
du nom complet, mais il est fréquemment tronqué du libellé complet et aussi
dans le champ adhoc du mot directeur, et alors plus unique du tout, et pas
unique non plus après les fusions de communes (MAIRIE, EGLISE, POSTE,
MARCHE, GAULLE, LIBERATION, SOUVENIR, HUGO, sont parmi les plus courants on
peut y ajouter certaines dates comme 1918 et 1945 et des noms de grandes
villes comme PARIS, puisque nombre de voies en France sont dirigées vers
elles, même s'il y a plein de chemin possibles et que ce n'est pas si
discriminant que ça, notamment les noms de communes les plus proches).
Ce mot "directeur" n'est qu'un outil de recherche qui permet de réduire le
nombre d'occurences trouvées. Si seulement les communes étaient un peu plus
originales et se servaient de leur patrimoine local de typonymes et non sur
le supposé "prestige" des célébrités à la mode (qui peut changer selon
l'orientation politique) !


Le jeu. 19 déc. 2019 à 17:05, Christian Quest  a
écrit :

> Le mot directeur, c'est celui qui est le plus discriminant dans le nom:
>
> Avenue du Général Leclerc -> Leclerc
> Place de la Mairie -> Mairie
>
> Dans les bonnes pratiques, il doit être unique dans la commune, comme ça
> on évite plein de problèmes !
>
> C'est réducteur, mais efficace. Il figure d'ailleurs en tant que tel dans
> le fichier FANTOIR et dans ceux de La Poste.
>
>
> Le jeu. 19 déc. 2019 à 13:46, Christian Rogel <
> christian.ro...@club-internet.fr> a écrit :
>
>> Christian Q. a mentionné un mot-directeur. A quoi fait-il référence ?
>>
>
> --
> 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] Noms de rue, osmose et bano V2

Le 3e nom (type 0) n'est pas vraiment bon nom plus: "LOT" est repris du
deuxième nom (type A) où c'était l'abréviation générique de "lotissement"
(nature de voie).
Dans tout ça ça donnerait l'adresse "Voie Lotissement Dona Maria", mais là
clairement soit c'est "Lotissement Dona Maria", soit "Voir Dona Maria".
On dirait que l'ajout de "LOT" en préfixe du 2e libellé n'est là que parce
qu'il faudrait unicité du couple nature_voie+libelle_voie.

On se demande alors la raison d'être de cette séparation des champs
"nature_voie" et "libelle_voie", qui en fin de compte n'en forment qu'un
seul indissociable (mais dont la première partie est abrégé selon la
nomenclature standard ou vide, sinon la seconde n'obéit à aucune règle :
abréviations quelconques, troncature... Même la poste n'exige pas cette
séparation sur les lignes d'adresse normalisées (où il n'y a aucun
séparateur autre que l'espace, même pour l'apostrophe)

Ensuite à quoi sert le code du type de voie entre le code commune et le
numéro de voie RIVOLI ? Lui non plus n'obéit à aucune règle
d'attribution... de fait le FANTOIR est obligé de rajouter un autre champ
(non figuré ici) pour indiquer comment l'interpréter  Bref "B051" ou "A025"
ou "0131" sont seulement des codes de voie par commune (ou ancienne
commune...) indissociables de 4 caractères quelconques (chiffres ou lettres
capitales sauf I,O,Q).

RIVOLI, même rebaptisé maintenant FANTOIR, semble toujours n'être qu'un
chantier de transition pas terminé et pas cohérent.

Que dire ensuite de sa stabilité dans le temps : des tas de codes changent
sans raison (pas seulement les codes temporaires "Z" qui théoriquement
devraient avoir un code finalisé, mais peuvent disparaitre aussi
complètement d'une année à l'autre). Et avec les fusions de communes on ne
s'y retrouve plus: l'unicité des codes voies sur 4 caractères par commune
n'est plus garantie, pas plus que les noms (voies ou lieux-dits).

Il y a encore du gros travail à faire sur cette nomenclature instable (et à
mettre d'accord la DGFIP avec ses fournisseurs de données: mairies, CCI,
chambres d'agriculture, La Poste et ses nouveaux concurrents). D'ailleurs
les concurrents de la Poste préfèrent utiliser une autre nomenclature plus
précise à eux et plus stable (ex. DHL, Amazon, etc.), et se foutent pas mal
de nos codes postaux qui ne veulent pas dire grand chose non plus et où la
Poste a fait n'importe quoi au gré de ses réorganisations internes.


Le jeu. 19 déc. 2019 à 16:56, lenny.libre  a écrit :

>
> Le 19/12/2019 à 13:16, Vincent de Château-Thierry a écrit :
>
> Bonjour,
>
>
> De: "Vincent Bergeot"  
>
> Oui il va falloir aller voir sur le terrain pour départager mais je
> me demande si ces outils qualités se parlent et surtout comment ils
> se parlent ? Entendu par là que j'ai l'impression que la qualité de
> l'un n'est pas exploité par l'autre et que la qualité de l'autre
> n'est pas exploité par l'un :D
>
> C'est peut-être une évidence évidente sachant que les sources de
> "comparaisons sont différentes" mais cela m'intrigue :)
>
> Non rien d'évident :).
> Je ne sais pas ce qu'Osmose vient piocher dans BANO, a fortiori dans quelle 
> version de BANO. Dans l'autre sens BANO n'interroge pas Osmose comme source 
> ou comme intermédiaire vers d'autres sources, la démarche de comparaison avec 
> le Cadastre et Fantoir se fait en direct.
>
> vincent
>
> Je pense qu'il faut regarder le fichier dans un cas où il y a deux codes
> fantoir proposés, si on regarde dans le fichier Fantoir, on peut voir qu'il
> y a 3 enregistrement concernant ton cas
>
> Fantoir OSM nature_voie libelle_voie
> 64125B051K
> DONA MARIA
> 64125A025V LOT DONA MARIA
> 641250131R VOIE LOT DONA MARIA
>
> Le rapprochement à été fait avec le premier : 64125B051K, si je prends la
> premier caractère du code rivoli c'est-à-dire "B" c'est d’après le wiki une
> lettre de B à W pour les lieux-dits (habités ou non)
>
> Osmose propose le troisième : 641250131R, si je prends la premier
> caractère du code rivoli c'est-à-dire "0" c'est un chiffre de 0 à 9 pour
> les voies du domaine public
>
> Quand au deuxième "A" une lettre A pour les ensembles immobiliers
> (résidences, lotissements privés, copropriétés) dont la voirie interne ne
> fait pas partie du domaine public
>
> Donc, mon sentiment c'est que le bon FANTOIR de ta rue c'est le troisième
> et si sur le nom de la rue est bien celui d'OSM, j'écouterais Osmose pour
> la modif du FANTOIR, mais pas du nom, et je modifierais le status FANTOIR
> dans le fichier
>
> Cordialement
>
> Leni
> ___
> 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] Joli noms de rues

Le mer. 18 déc. 2019 à 11:52, Alain Rpnpif  a écrit :

>
> Bonjour,
>
> En rural, la numérotation des maisons hors bourg est basée en Bretagne
> depuis quelques années sur la distance par rapport au début de la rue :
> le problème est qu'on ne sait jamais où commence la rue ou le chemin qui
> peut être très long. Cela explique les grands nombres pour les numéros
> comme 1039 (mètres). D'après des élus, ce serait une lubie de la Poste.
>
>
Cela a des avantages:
- plus de bis/ter à créer ;)
- tu vois 2 numéros et tu sais dans quel sens aller (comme en numérotation
séquentielle d'ailleurs)
- tu as une idée de la proximité de ta destination

En rural, les adresses peuvent être très espacées et c'est donc bien adapté.
La Poste est un peu radicale, manque surtout de pédagogie car elle
considère que l'adresse c'est SON truc.



> Avec la fibre optique et son « chantage » comme le dit Christian, les
> numéros deviennent un véritable Sudoku ;). Les maisons isolées seront
> bientôt numérotées en dizaines en Anjou mais suivant l'ancienne commune
> à l'intérieur de la nouvelle commune !
>
> Par exemple, toutes les habitations isolées auront comme adresse 30,
> suivi de leur nom de lieu-dit pour l'ancienne commune Mimosa à
> l'intérieur de la nouvelle Foire-en-Anjou. L'ancienne commune voisine
> Lilas dans cette même nouvelle commune, aura ses numéros de maison
> isolée en 20. S'il y en a deux dans le même lieu, la suivante aura 21.
> Vous me suivez ?
>
> L'avantage : distinguez des maisons ayant la même adresse (lieu-dit) à
> l'intérieur de la même nouvelle commune (si si, c'est très fréquent et
> cela existe même à l'intérieur des anciennes communes, j'ai des exemples
> à 1 km de chez moi).
>
>
Pour ça que donner des noms aux voies est mieux que ces bricolages avec les
lieux-dits, surtout quand ils sont homonymes !


L'inconvénient : Une véritable usine à gaz... et du travail pour OSM ;).
>
>
Ingérable sur le terrain si tu n'a pas une carte ou un GPS...


En conclusion, je signe ce que dit Christian ; respect de la population
> (cela n'a pas été le cas dans le coin de Bretagne mentionné vu les
> oppositions locales face à la disparition inutiles de noms connus depuis
> toujours).
>
>

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

Re: [OSM-talk-fr] Nommage/Numérotation hameaux (Était : Re: Joli noms de rues)

Le mot directeur, c'est celui qui est le plus discriminant dans le nom:

Avenue du Général Leclerc -> Leclerc
Place de la Mairie -> Mairie

Dans les bonnes pratiques, il doit être unique dans la commune, comme ça on
évite plein de problèmes !

C'est réducteur, mais efficace. Il figure d'ailleurs en tant que tel dans
le fichier FANTOIR et dans ceux de La Poste.


Le jeu. 19 déc. 2019 à 13:46, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

> Christian Q. a mentionné un mot-directeur. A quoi fait-il référence ?
>

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

Re: [OSM-talk-fr] Noms de rue, osmose et bano V2

J'ai une analyse osmose qui remonte les gros rouge qui tâchent, c'est de ça
dont on parle.

Oui, il faudra la revoir... comme le rendu BANO (sur ma tout doux liste).


Le jeu. 19 déc. 2019 à 13:18, Vincent de Château-Thierry 
a écrit :

> Bonjour,
>
> > De: "Vincent Bergeot" 
> >
> > Oui il va falloir aller voir sur le terrain pour départager mais je
> > me demande si ces outils qualités se parlent et surtout comment ils
> > se parlent ? Entendu par là que j'ai l'impression que la qualité de
> > l'un n'est pas exploité par l'autre et que la qualité de l'autre
> > n'est pas exploité par l'un :D
> >
> > C'est peut-être une évidence évidente sachant que les sources de
> > "comparaisons sont différentes" mais cela m'intrigue :)
>
> Non rien d'évident :).
> Je ne sais pas ce qu'Osmose vient piocher dans BANO, a fortiori dans
> quelle version de BANO. Dans l'autre sens BANO n'interroge pas Osmose comme
> source ou comme intermédiaire vers d'autres sources, la démarche de
> comparaison avec le Cadastre et Fantoir se fait en direct.
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Noms de rue, osmose et bano V2

2019-12-19 Per discussione lenny.libre



Le 19/12/2019 à 13:16, Vincent de Château-Thierry a écrit :

Bonjour,


De: "Vincent Bergeot" 

Oui il va falloir aller voir sur le terrain pour départager mais je
me demande si ces outils qualités se parlent et surtout comment ils
se parlent ? Entendu par là que j'ai l'impression que la qualité de
l'un n'est pas exploité par l'autre et que la qualité de l'autre
n'est pas exploité par l'un :D

C'est peut-être une évidence évidente sachant que les sources de
"comparaisons sont différentes" mais cela m'intrigue :)

Non rien d'évident :).
Je ne sais pas ce qu'Osmose vient piocher dans BANO, a fortiori dans quelle 
version de BANO. Dans l'autre sens BANO n'interroge pas Osmose comme source ou 
comme intermédiaire vers d'autres sources, la démarche de comparaison avec le 
Cadastre et Fantoir se fait en direct.

vincent


Je pense qu'il faut regarder le fichier dans un cas où il y a deux codes 
fantoir proposés, si on regarde dans le fichier Fantoir, on peut voir 
qu'il y a 3 enregistrement concernant ton cas


Fantoir OSM nature_voie libelle_voie
64125B051K  
DONA MARIA
64125A025V  LOT DONA MARIA
641250131R  VOIELOT DONA MARIA

Le rapprochement à été fait avec le premier : 64125B051K, si je prends 
la premier caractère du code rivoli c'est-à-dire "B" c'est d’après le 
wiki une lettre de B à W pour les lieux-dits (habités ou non)


Osmose propose le troisième : 641250131R, si je prends la premier 
caractère du code rivoli c'est-à-dire "0" c'est un chiffre de 0 à 9 pour 
les voies du domaine public


Quand au deuxième "A" une lettre A pour les ensembles immobiliers 
(résidences, lotissements privés, copropriétés) dont la voirie interne 
ne fait pas partie du domaine public


Donc, mon sentiment c'est que le bon FANTOIR de ta rue c'est le 
troisième et si sur le nom de la rue est bien celui d'OSM, j'écouterais 
Osmose pour la modif du FANTOIR, mais pas du nom, et je modifierais le 
status FANTOIR dans le fichier


Cordialement

Leni

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

Re: [OSM-talk-fr] Orthos: mise à jour 2018 sur de nombreux départements

Elle n'est peut être pas dans les presets... il faut dire que c'est une
couche composite, pas simple à gérer pour l'attribution !

Pour info, nouveaux départements en version 2018: 02 59 60 62 80

Certains sont dispo pour la première fois (02/60/80).


Le mer. 18 déc. 2019 à 18:22, David Crochet  a
écrit :

> Bonjour
>
> Le 17/12/2019 à 12:14, Christian Quest a écrit :
> > - tous_fr : qui est combinaisons de toutes les orthos, en priorisant
> > la date puis la résolution
>
>
> Je ne le trouve pas disponible dans JOSM, il faut le rajouter à la main ?
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Projet Europeen de l'Eau/European Water Project - Introduction

C'est fait: https://twitter.com/cq94/status/1207689204953755648

Le mer. 18 déc. 2019 à 16:31, marc marc  a
écrit :

> Le 18.12.19 à 13:38, Romain MEHUT a écrit :
> > marc marc wrote
> >> source : données livres, cartes libres, utilisateurs
> >> c'est versé dans osm ou ils ont réinventé la roue ?
> >
> > Voir cet échange via Twitter :
> > https://twitter.com/Hoali_org/status/1164078027472613377
>
> pour mémoire, il s'y dit :
> Les données sont un mix de données ouvertes dont @openstreetmap, mais
> aussi des bases de données de cyclistes et de livreurs à vélo et de la
> contribution des usagers. Les données générée seront repartagés sur
> @openstreetmap.
>
> cquest a réclamé l'attribution manquante.
> pas de trace de la base obdl sous odbl vu la fusion de bdd
> pas souvenir d'avoir entendu parler d'un import de leur part
> si quelqu'un a envie de les relancer sur Twitter :)
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Joli noms de rues

2019-12-19 Per discussione Alain Rpnpif


Le 18/12/2019 à 09:48, Christian Quest a écrit :

Le mer. 18 déc. 2019 à 02:11, > a écrit :


Mais j'ai une question : où figure l'obligation de nommer les rues
? Je croyais que l'obligation était d'avoir des adresses.


Il n'y a même pas d'obligation forte pour les adresses.
Il y a une obligation faible, surtout avec le chantage au déploiement 
de la fibre ("pas d'adresse pas de fibre") et un peu aussi lié à 
l'organisation des secours.


Mon hameau a été numéroté, il y a par contre 3 rues/routes qui
n'ont pas de nom.

De mon point de vue c'est une connerie d'attribuer des numéros dans un 
hameau sans que ça fasse référence à une voie de circulation.


Pourquoi ?

Pour trouver une adresse, on commence par trouver la voie, puis on la 
suit dans l'ordre des numéros. C'est un système simple et efficace.
Des numéros désordonnés sans logique linéaire dans un hameau ne sont 
pas facilement trouvables vu qu'il n'y a pas d'ordre naturel ou 
conventionnel.
Une numérotation désordonnée, on en a déjà une, les numéros de 
parcelle, pas besoin d'une seconde ;)


On peut les "nommer" en utilisant le nom du hameau suivant (c'est
la route en direction de...). Et c'est suffisant.

Ce n'est pas un nom car les hameaux autour du hameau suivant
auront la même description.

Il suffit de prendre une carte OSM.

Oui, comme on ne trouve pas les numéros désordonnés, on a besoin d'une 
carte...


Pour le déploiement de la fibre, ça n'a aucun impact, il suffit que 
l'adresse soit dans une base de données, l'aspect terrain est 
totalement secondaire (sauf pour l'installation, qui se fait une fois 
pour toute).
Pour les secours (ou les livraisons)... si ils n'ont pas la carte, les 
numéros désordonnés sont plus difficiles à localiser que ceux ordonnés 
le long d'une voie.



Le choix pour les noms de rues est important lui aussi...
- avoir un "mot directeur"
- éviter les homonymies (chemin machin / impasse machin), le mot 
directeur ne devrait être utilisé qu'une seule fois

- éviter les noms exotiques... car on augmente les fautes de saisies

Les mauvais choix (de nom ou de logique de numérotation) ont des 
impacts pour les habitants. De plus les changements pour rectifier des 
erreurs dans ce choix ont encore plus d'impacts... il ne faut donc pas 
faire n'importe quoi, en premier par respect pour la population.

Bonjour,

En rural, la numérotation des maisons hors bourg est basée en Bretagne 
depuis quelques années sur la distance par rapport au début de la rue : 
le problème est qu'on ne sait jamais où commence la rue ou le chemin qui 
peut être très long. Cela explique les grands nombres pour les numéros 
comme 1039 (mètres). D'après des élus, ce serait une lubie de la Poste.


Avec la fibre optique et son « chantage » comme le dit Christian, les 
numéros deviennent un véritable Sudoku ;). Les maisons isolées seront 
bientôt numérotées en dizaines en Anjou mais suivant l'ancienne commune 
à l'intérieur de la nouvelle commune !


Par exemple, toutes les habitations isolées auront comme adresse 30, 
suivi de leur nom de lieu-dit pour l'ancienne commune Mimosa à 
l'intérieure de la nouvelle Foire-en-Anjou. L'ancienne commune voisine 
Lilas dans cette même nouvelle commune, aura ses numéros de maison 
isolée en 20. S'il y en a deux dans le même lieu, la suivante aura 21. 
Vous me suivez ?


L'avantage : distinguez des maisons ayant la même adresse à l'intérieur 
de la même nouvelle commune (si si, c'est très fréquent et cela existe 
même à l'intérieur des anciennes communes, j'ai des exemples à 1 km de 
chez moi).


L'inconvénient : Une véritable usine à gaz... et du travail pour OSM ;).

-- Rpnpif

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

Re: [OSM-talk] What does WGS84 mean for openstreetmap these days?

2019-12-19 Per discussione Jóhannes Birgir Jensson

Hello Greg

I don't think we can or will be providing accuracy up to cm when most of the 
stuff we map from our chairs is off by a meter or two anyways - the beauty is 
that it doesn't matter for 99,99% of users. If a centimeter matters then we are 
probably dealing with legal matters and there OSM makes it quite clear it is 
not suitable for such.

Also regarding the accuracy, as another fast moving country Iceland is actually 
splitting in the middle and so it edges west and east and south as well, 
depending on where you are in the country. We've had 3 official national datums 
now, ISN93, ISN2004 and ISN2016 (helpfully naming them after years). The fact 
is that pretty much everything is still running in ISN93, ISN2004 saw very 
little uptake and ISN2016 has started very slowly.

So for Iceland we do know that we are never going to achieve a centimeter 
accuracy, pretty much ever, and don't expect a free people sourced geographical 
database to reach it.

--Jóhannes / Stalfur


19. desember 2019 kl. 14:37, skrifaði "Greg Troxel" :

> (This is a long and complicated subject and I am intentionally asking
> only part of the question.)
> 
> It's been said from the beginning that coordinates in the openstreetmap
> datbase are in "WGS84". That more or less meant "what a GPS receiver
> showed", back in the days when GPS was the GNSS system of choice and
> accuracies were low compared to talking about versions of WGS84.
> 
> In discussion on the proj list, it seems the consensus view is that
> WGS84 is now a term that refers to any one of the 6 realizations of
> WGS84 over time. This makes sense when you have data that is merely
> labeled WGS84, without a more specific label such as WGS84(G1762). This
> means that WGS84 is considered low accuracy (because the original was),
> and thus any transforms involving it are assigned high error values.
> 
> This page has a good overview of the various WGS84 realizations and
> their relationship to ITRF realizations:
> 
> https://www.e-education.psu.edu/geog862/node/1804
> 
> As normal people (or at least normal nerds) get access to more accurate
> positions, this question begins to matter, as in North America positions
> in original WGS84 and modern WGS84 differ by more than a meter.
> 
> I should note that now that WGS84 has converged to ITRF, and new ITRF
> realizations seem to be at most cm-level changes from previous ones, I
> do not expect future WGS84 revisions to be signficantly different from
> either the current one.
> 
> So, I wonder if we want to change the definition for OSM coordinates
> from "WGS84" to "the realization of WGS84 currently in use by GPS".
> That doesn't change older coordindates (and I am not suggesting any
> automated changes!!!). But it does give a notion of what coordinates
> should be, both in using them and in producing new ones for editing. I
> expect that this will have zero practical effect for most people, but
> will allow higher accuracy for those who are into extreme accuracy.
> 
> postscript:
> 
> I am intentionally leaving out of this discussion two more issues (which
> could result in further changes, with much more complexity). I list
> them so that those with some background in geodesy can begin to ponder,
> and to explain that my stopping at the proposal above was intentional.
> 
> 1) WGS84 is a US datum. BEIDOU, GALILEO, GLONASS use different datums.
> SBAS systems also use different datums -- WAAS seems to give
> coordinates in "ITRF2000 (current epoch)". It seems most are
> equivalent to some modern ITRF, with possibly differing epochs.
> 
> (I will assume for point 2 that there OSM redefines coordinates to be a
> particular ITRF at a particular epoch, probably matching the current
> WGS84.)
> 
> 2) ITRF is global, but objects we map are generally crust-fixed on some
> plate. The US has a (mostly, if you're not in CA) crust-fixed datum,
> NAD83, and other countries do too. This is particularly acute in
> Australia which is a notably fast-moving country :-) The modern trend is
> for stations to have velocities and not just coordinates. Over 20
> years, this starts to matter. Several countries are introducing new
> national datums that are intended to address some of these issues. I
> don't think it makes sense for OSM to deal with this issue for a few
> years.
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [Talk-GB] barrier=kerb on highways may be blocking OSRM (Car) routing

2019-12-19 Per discussione Edward Catmur via Talk-GB

Good idea - I've added a pull request to Osmose
https://github.com/osm-fr/osmose-backend/pull/714 - please take a look and
weigh in if you think it could be improved.

On Wed, Dec 18, 2019 at 4:47 PM Ken Kilfedder 
wrote:

> Is it worth adding this to Osmose and the other QA tools?
>
> ---
> https://hdyc.neis-one.org/?spiregrain
> spiregrain_...@ksglp.org.uk
>
>
> On Wed, 18 Dec 2019, at 4:31 PM, Edward Catmur via Talk-GB wrote:
>
> Further to this - if you want to look for barrier=kerb + highway=crossing
> nodes in your area, which may be disrupting routing, the Overpass query
> is node["barrier"="kerb"]["highway"="crossing"] :
> https://overpass-turbo.eu/s/P5Y
>
> On Wed, Dec 18, 2019 at 4:20 PM Edward Catmur 
> wrote:
>
> Returning to the original issue, I think I've worked out what the problem
> is. It's that on a crossing node, kerb=* is fine (it describes the
> presence/attributes of the kerb on the subsidiary highway) but barrier=kerb
> should *not* be used.
>
> Combining kerb=* with highway=crossing is blessed by Wiki:
>
>  If the kerb is identical on both sides of a crossing, it is possible to
> add the kerb=* tag to the highway
> =crossing
>  node, which
> sacrifices accuracy for simplicity, consider using kerb:left and kerb:right
> if the kerbs differ.
>
>
> but this doesn't say that barrier=kerb should be included on the crossing
> node!
>
> I think barrier=kerb + highway=crossing should be regarded as a mistake.
> Taginfo shows ~ 1000 of them (0.47 of barrier=kerb nodes; 0.03% of
> highway=crossing nodes) which should fixable.
>
> On Wed, Dec 18, 2019 at 3:37 PM Philip Barnes 
> wrote:
>
> On Wednesday, 18 December 2019, David Woolley wrote:
> > On 18/12/2019 13:31, Edward Catmur via Talk-GB wrote:
> > > That said, the same goes for cars - other than the lowest bodied
> sports
> > > cars, pretty much all motor vehicles are capable of taking a kerb at
> low
> > > speed.
> >
> > Although raised kerbs are generally there to stop that happening and the
> > resultant trespass on the footway can be illegal, e.g. in London.  As
> > such routers should not be routing motor vehicles over kerbs.
>
> Its a level of detail that few of us have mapped, but it is perfectly
> acceptable, and quite common, to route motor vehicles  over lowered kerbs
> to access private property.
>
> Phil (trigpoint)
>
>
>
>  ___
> > Talk-GB mailing list
> > Talk-GB@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-gb
> >
>
> --
> Sent from my Sailfish device
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] No Through Road Ahead

2019-12-19 Per discussione Paul Berry

I think it's 13 metres, according to:
https://www.highwaycodeuk.co.uk/vehicle-markings.html (these markings
replaced the old "LONG VEHICLE" plates that were mandated; I presume they
correspond to mentions of "long vehicles" on road signage too).

I wait to be corrected however.

Regards,
*Paul*

On Thu, 19 Dec 2019 at 14:35, Peter Neale via Talk-GB <
talk-gb@openstreetmap.org> wrote:

> I can see the logic of placing the restriction on the bend, but how long
> is a "long vehicle"?
>
> Is there an official definition?
>
> Peter
>
> Sent from Yahoo Mail on Android
> 
>
> On Thu, 19 Dec 2019 at 14:30, SK53
>  wrote:
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] What does WGS84 mean for openstreetmap these days?

2019-12-19 Per discussione Simon Poole

Thus is a slightly tricky subject and it is not going away.

For another aspect of it see
https://www.openstreetmap.org/user/StephaneP/diary/390290

Essentially in some cases we are using imagery that isn't actually using
WGS84 as if it was (fsvo of WGS84 as you correctly point out) and we
currently don't actually have a way to correct this . And yes while
continental shift is for most countries smaller than all the other ones
when adding geometry, for Australia this not necessarily true.

Simon

Am 19.12.2019 um 15:33 schrieb Greg Troxel:
> (This is a long and complicated subject and I am intentionally asking
> only part of the question.)
>
> It's been said from the beginning that coordinates in the openstreetmap
> datbase are in "WGS84".  That more or less meant "what a GPS receiver
> showed", back in the days when GPS was the GNSS system of choice and
> accuracies were low compared to talking about versions of WGS84.
>
> In discussion on the proj list, it seems the consensus view is that
> WGS84 is now a term that refers to any one of the 6 realizations of
> WGS84 over time.  This makes sense when you have data that is merely
> labeled WGS84, without a more specific label such as WGS84(G1762).  This
> means that WGS84 is considered low accuracy (because the original was),
> and thus any transforms involving it are assigned high error values.
>
> This page has a good overview of the various WGS84 realizations and
> their relationship to ITRF realizations:
>
>   https://www.e-education.psu.edu/geog862/node/1804
>
>
> As normal people (or at least normal nerds) get access to more accurate
> positions, this question begins to matter, as in North America positions
> in original WGS84 and modern WGS84 differ by more than a meter.
>
> I should note that now that WGS84 has converged to ITRF, and new ITRF
> realizations seem to be at most cm-level changes from previous ones, I
> do not expect future WGS84 revisions to be signficantly different from
> either the current one.
>
> So, I wonder if we want to change the definition for OSM coordinates
> from "WGS84" to "the realization of WGS84 currently in use by GPS".
> That doesn't change older coordindates (and I am not suggesting any
> automated changes!!!).  But it does give a notion of what coordinates
> should be, both in using them and in producing new ones for editing.  I
> expect that this will have zero practical effect for most people, but
> will allow higher accuracy for those who are into extreme accuracy.
>
>
> postscript:
>
> I am intentionally leaving out of this discussion two more issues (which
> could result in further changes, with much more complexity).  I list
> them so that those with some background in geodesy can begin to ponder,
> and to explain that my stopping at the proposal above was intentional.
>
> 1) WGS84 is a US datum.  BEIDOU, GALILEO, GLONASS use different datums.
>SBAS systems also use different datums -- WAAS seems to give
>coordinates in "ITRF2000 (current epoch)".  It seems most are
>equivalent to some modern ITRF, with possibly differing epochs.
>
> (I will assume for point 2 that there OSM redefines coordinates to be a
> particular ITRF at a particular epoch, probably matching the current
> WGS84.)
>
> 2) ITRF is global, but objects we map are generally crust-fixed on some
> plate.  The US has a (mostly, if you're not in CA) crust-fixed datum,
> NAD83, and other countries do too.  This is particularly acute in
> Australia which is a notably fast-moving country :-) The modern trend is
> for stations to have velocities and not just coordinates.  Over 20
> years, this starts to matter.  Several countries are introducing new
> national datums that are intended to address some of these issues.  I
> don't think it makes sense for OSM to deal with this issue for a few
> years.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



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

Re: [OSM-talk-fr] Nommage/Numérotation hameaux (Était : Re: Joli noms de rues)

Noter que la numérotation par "bloc" et non par voie est monnaie courante
dans certains pays (Japon, Afrique, Amérique du Sud), mais aussi dans les
zones d'activité et pépinières d'entreprises. Ce qui justifie aussi un
addr:place=*+addr:house=* sans aucun addr:street=*. Au Japon et en Chine,
il y a un découpage en plein de niveaux de blocs et sous-blocs, nommés ou
numérotés en dessous du niveau de la collectivité locale (parler de
"commune" est une vision assez européenne sur la façon dont
l'adminsitration est décentralisée de façon hiérarchique et égalitaire,
alors qu'ailleurs il n'y a pas de structures dédiée à un niveau
particulier, chaque niveau définissant son organisation interne sans que ce
soit totalement standardisé au plan national.
Les statuts de "villes", "towns/cities" et les particularismes sont
nombreux, même aux USA et au Royaume-Uni (même si aux USA les routes sont
très rectilignes, les blocs séparés par les voies publiques sont souvent
assez grands pour avoir une organisation interne privée ne suivant pas les
règles communes, hors des grandes métropoles où la densité de résidents
s'est plus ou moins standardisée par les couts du marché pour des surfaces
équivalentes et la proximité de certains services (tout n'est pas
exactement taillé selon une grille, et il y a des tas de chemins sans noms,
ça finit par une numérotation par bloc, avec éventuellement seulement un
ordonnancement linéraire des "plages" de numéros attribuées à chaque bloc).

Ca n'empêche pas d'avoir aussi des noms de rues, pour les directions à
suivre pour se rendre au bloc, mais pas pertinent pour les adresses car les
numéros ne sont alors pas uniques sur toute la voie. Les numéros ne sont
pas toujours linéaires et séquentiels non plus le long des voies qui
bordent ces blocs, et pas toujours numériques non plus (ils peuvent même
être des noms privés ou mixtes: chiffres et lettres selon plus ou moins une
grille, avec des trous créés volontairement pour les zones aménageables).


Le jeu. 19 déc. 2019 à 14:56,  a écrit :

> Le 19/12/2019 à 13:44, Christian Rogel - christian.ro...@club-internet.fr
> a écrit :
>
> D’autant que, la présence de noms en langue autre que le français ne peut 
> génèrer qu’une multitude de faux positifs.
>
> Non, par rue de associatedStreet on entend highway=xxx, peu importe que ce
> soit une rue, route, peu importe qu'elle s'appelle Rue, Chemin, Hent ou
> Strasse.
>
> Le problème pour utiliser associatedStreet pour autre chose que des
> highway c'est qu'on n'a pas la même topologie: qu'un côté on a du filaire
> (highway=) et de l'autre du surfacique (place d'une relation) ou du
> ponctuel (place seul ou comme admin center).
>
> Si tu acceptes du surfacique sur du associatedStreet pour une place je
> vous plusieurs problèmes :
>
> - une rue associée, c'est une rue, associatedHighway aurait été un
> meilleur nom mais bon. Si tu mets du surfacique avec un tel nom tu sous
> entend area:highway c'est à dire la bande de roulement et non la voirie
> plus les numéros d'adresses (plus les parcelles accessibles depuis cette
> route en direct).
>
> - pour une place, le surfacique c'est l'enveloppe complète à savoir les
> rues mais aussi les terrains accessibles depuis ces rues.
>
> Si on mélange deux concepts pour un même schéma on va chercher les
> embrouilles. Même si on pourrait s'en sortir en mettant des membres ayant
> pour role boundary pour délimiter une place=, suaf que ça doublonnerait les
> relations type=boundary.
>
> C'est pourquoi je propose d'utiliser les relations boundary=place pour
> obtenir l'équivalent de associatedStreet : même modélisation des membres
> house mais autres attributs en tête (tout en partageant par exemples *name*
> et ref:FR:FANTOIR).
>
> Ça permet de factoriser comme associatedStreet sans faire
> d'associatedStreet une chimère.
>
> Note : pour les places sans zonage bien défini - heu si c'est numéroté
> c'est bien que la limite est assez nette - on peut ne mettre aucun way pour
> définir le périmètre et se contenter d'un nœud label pour un indice de
> l'endroit où afficher la place.
>
>  »Address:place« .  accompagné d'un numéro paraît donc une fantaisie peu 
> utile.
>
> Ça permet de dire que le numéro correspond à une adresse dans un lieu-dit.
> Je ne vois pas ce que ça a de fantaisiste.
>
> Ce qui est fantaisiste comme dit Christian Quest c'est de numéroter des
> hameaux plutôt que de nommer des voies et numéroter ces voies.
>
> Mais ça, OSM n'y peut pas grand chose.
>
> Jean-Yvon
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouvelles données ouvertes sur les réseaux électriques

2019-12-19 Per discussione Vincent de Château-Thierry


> De: "HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE PPE)" 
> 
> 
> Bravo François pour ton engagement souterrain comme aérien et sans
> failles.

Oh ce parfait résumé <3

Bravo à tous et surtout à toi François, au front sur ces sujets

vincent

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

Re: [OSM-talk-be] Mapillary

2019-12-19 Per discussione Guy Vanvuchelen

Bedankt voor de info, maar……..

Na nog wat proberen denk ik dat als je één foto selecteert de hele sequentie, 
waar die foto deel van uitmaakt, blauw kleurt en zo blijft tot je een foto uit 
een andere sequentie selecteerdt

Hier in de buurt zijn door minstens drie personen opnames gemaakt: Polyglot, 
Filipc en ikzelf (GuyVV) en ze kleuren allemaal blauw als je ze selecteert.

Maar ik begrijp niet hoe het kan dat in Mapillary de foto’s niet getoond worden 
en in JOSM wel  (Driebek, Tienen) terwijl JOSM ze uit Mapillary haalt.

 

 

Guy Vanvuchelen

 

Van: Georges De Gruyter [mailto:zors1...@gmail.com] 
Verzonden: donderdag 19 december 2019 13:40
Aan: OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] Mapillary

 

Blauwe lijnen zijn je eigen foto’s, Guy.

 





Op 19 dec. 2019, om 13:14 heeft Guy Vanvuchelen  het 
volgende geschreven:

 

Kan iemand me vertellen hoe het komt dat ik bepaalde stukken uit een  fotoserie 
niet zie op Mapillary en wel in JOSM. (zie bijlage)

Wat is het verschil tussen blauw en groen?

 

Guy Vanvuchelen

 

 

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

 

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

[OSM-talk] What does WGS84 mean for openstreetmap these days?

2019-12-19 Per discussione HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE PPE)

(This is a long and complicated subject and I am intentionally asking
only part of the question.)

It's been said from the beginning that coordinates in the openstreetmap
datbase are in "WGS84".  That more or less meant "what a GPS receiver
showed", back in the days when GPS was the GNSS system of choice and
accuracies were low compared to talking about versions of WGS84.

In discussion on the proj list, it seems the consensus view is that
WGS84 is now a term that refers to any one of the 6 realizations of
WGS84 over time.  This makes sense when you have data that is merely
labeled WGS84, without a more specific label such as WGS84(G1762).  This
means that WGS84 is considered low accuracy (because the original was),
and thus any transforms involving it are assigned high error values.

This page has a good overview of the various WGS84 realizations and
their relationship to ITRF realizations:

  https://www.e-education.psu.edu/geog862/node/1804


As normal people (or at least normal nerds) get access to more accurate
positions, this question begins to matter, as in North America positions
in original WGS84 and modern WGS84 differ by more than a meter.

I should note that now that WGS84 has converged to ITRF, and new ITRF
realizations seem to be at most cm-level changes from previous ones, I
do not expect future WGS84 revisions to be signficantly different from
either the current one.

So, I wonder if we want to change the definition for OSM coordinates
from "WGS84" to "the realization of WGS84 currently in use by GPS".
That doesn't change older coordindates (and I am not suggesting any
automated changes!!!).  But it does give a notion of what coordinates
should be, both in using them and in producing new ones for editing.  I
expect that this will have zero practical effect for most people, but
will allow higher accuracy for those who are into extreme accuracy.


postscript:

I am intentionally leaving out of this discussion two more issues (which
could result in further changes, with much more complexity).  I list
them so that those with some background in geodesy can begin to ponder,
and to explain that my stopping at the proposal above was intentional.

1) WGS84 is a US datum.  BEIDOU, GALILEO, GLONASS use different datums.
   SBAS systems also use different datums -- WAAS seems to give
   coordinates in "ITRF2000 (current epoch)".  It seems most are
   equivalent to some modern ITRF, with possibly differing epochs.

(I will assume for point 2 that there OSM redefines coordinates to be a
particular ITRF at a particular epoch, probably matching the current
WGS84.)

2) ITRF is global, but objects we map are generally crust-fixed on some
plate.  The US has a (mostly, if you're not in CA) crust-fixed datum,
NAD83, and other countries do too.  This is particularly acute in
Australia which is a notably fast-moving country :-) The modern trend is
for stations to have velocities and not just coordinates.  Over 20
years, this starts to matter.  Several countries are introducing new
national datums that are intended to address some of these issues.  I
don't think it makes sense for OSM to deal with this issue for a few
years.

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

Re: [Talk-GB] No Through Road Ahead

2019-12-19 Per discussione Peter Neale via Talk-GB

I can see the logic of placing the restriction on the bend, but how long is a 
"long vehicle"?
Is there an official definition?
Peter

Sent from Yahoo Mail on Android 
 
  On Thu, 19 Dec 2019 at 14:30, SK53 wrote:   
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
  
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Nommage des bâtiments scolaires / universitaires complexes

2019-12-19 Per discussione Arnaud Champollion


Le 18/12/2019 à 22:01, Romain MEHUT a écrit :
Cet exemple des SEGPA me gêne aussi depuis pas mal de temps car ce 
sont des structures rattachées à des collèges et  donc identifier ces 
SEGPA avec amenity=school fait doublon avec les collèges déjà en 
amenity=school.



J'ai ajouté la SEGPA du Collège Gassendi à Digne :

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

en essayant de me conformer à :

https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dschool#Sp.C3.A9cialisations

donc : school:FR=SEGPA

Mais je n'ai pas compris l'histoire de la balise de troisième niveau.



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

Re: [Talk-GB] No Through Road Ahead

2019-12-19 Per discussione David Woolley


On 19/12/2019 14:06, Martin Wynne wrote:

How to tag this road?

https://goo.gl/maps/B4kUxoR83ej9JXWQ8

There is no actual barrier, just a very sharp corner.


You tag the corner, not the road, as the sign is only advisory.

Unfortunately, I suspect the current tagging scheme may have difficulty 
encoding the turning circle restriction, especially in a way that 
routers understand.


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

Re: [OSM-talk-fr] Nouvelles données ouvertes sur les réseaux électriques

Bravo François pour ton engagement souterrain comme aérien et sans failles.

De : François Lacombe
Envoyé : jeudi 19 décembre 2019 15:21
À : Discussions sur OSM en français
Objet : [OSM-talk-fr] Nouvelles données ouvertes sur les réseaux électriques

Bonjour à tous,

Vous le savez, cela fait maintenant plus d'un an que je m’investis activement
pour motiver les 130 gestionnaires de réseaux de distribution électrique à
ouvrir la cartographie de leurs réseaux.
https://teamopendata.org/t/les-gestionnaires-de-distribution-electrique/1018

Suite aux deux avis CADA reçus favorables en septembre, les choses se
débloquent et les échanges sont de plus en plus nombreux avec les acteurs
concernés.

L'une des plus grosses société contactée, Gérédis dans les Deux-Sevres, a
libéré récemment la cartographie de son réseau, présumée sous licence ouverte.
https://www.geredis.fr/Open-data

On y trouve le réseau aérien comme souterrain, ce qui est une bonne nouvelle au
vu du périmètre concerné, plus de 250 communes.

Ce n'est pas tout :
Enedis nous fait également le plaisir de compléter la cartographie déjà libre
depuis avril 2018 avec son réseau souterrain. Ceci sur l'ensemble de la
métropole, sois plus de 400 000 km de réseau portant le total à plus d'1
million de km avec l'aérien.
Le jeu de données des postes est plus complet qu'avant, avec l'ajout des
installations non visibles (la plupart des postes parisiens par exemple).
https://data.enedis.fr/explore/dataset/reseau-souterrain-hta/map/?location=15,45.14656,1.49646=jawg.streets

De ma compréhension et c'est à souligner, de nombreux mois de travail semblent
avoir été nécessaires pour élaborer ces jeux de données avec l'investissement
de plusieurs équipes.
Cela renforce encore la pertinence d'inciter les entreprises à ouvrir leurs
données, si cela était encore à démontrer. Le sujet intéresse et est utile aux
structures qui publient.

L'effort devrait se poursuivre en 2020 avec l'établissement d'un standard
(j'espère), nécessaire pour accompagner les plus petites structures vers
l'ouverture et harmoniser les licences choisies.
Et pourquoi pas quelques services, si il reste du temps.

Ceci ne serait pas probablement pas possible si la communauté ne contribuait
pas aussi assidûment sur le sujet. Les acteurs concernés ont bien pris la
mesure de notre engagement et de ce que nous pouvions apporter au pot commun.
Ces progrès sont à mettre au crédit de nos efforts à tous.

Bonne fin de semaine

François
---
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-GB] No Through Road Ahead

2019-12-19 Per discussione SK53

I would model this with some kind of restriction: presumably maxlength on
the sharp bend.

Jerry

On Thu, 19 Dec 2019 at 14:07, Martin Wynne  wrote:

> How to tag this road?
>
>   https://goo.gl/maps/B4kUxoR83ej9JXWQ8
>
> There is no actual barrier, just a very sharp corner.
>
> Thanks.
>
> Martin.
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-us] Trunk VS primary,

2019-12-19 Per discussione Eric Ladner

I personally dislike "trunk".  Its definition is vague and leaves a lot to
interpretation (and argument).  It doesn't really add anything to the
information on the map, IMO.  A US Highway is a US Highway regardless of
how much traffic it carries or how many stoplights it has.

Maybe if the definition of "trunk" was solidified to something more
specific, it would have a more valuable use case.

On Thu, Dec 19, 2019 at 5:15 AM Mike N  wrote:

> On 12/17/2019 10:19 PM, Evin Fairchild wrote:
> > some US routes are more important than others and lumping them all as
> > primary doesn???t make any sense;
>
> The arguments here about relative importance of parallel routes makes
> sense.
>
>Some massive changes such as in
> https://www.openstreetmap.org/changeset/78620805 are raising roads which
> have no other major choices, but are apparently just because they are
> the most important.
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>

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

[OSM-talk-fr] Nouvelles données ouvertes sur les réseaux électriques

2019-12-19 Per discussione François Lacombe

Bonjour à tous,

Vous le savez, cela fait maintenant plus d'un an que je m’investis
activement pour motiver les 130 gestionnaires de réseaux de distribution
électrique à ouvrir la cartographie de leurs réseaux.
https://teamopendata.org/t/les-gestionnaires-de-distribution-electrique/1018

Suite aux deux avis CADA reçus favorables en septembre, les choses se
débloquent et les échanges sont de plus en plus nombreux avec les acteurs
concernés.

L'une des plus grosses société contactée, Gérédis dans les Deux-Sevres, a
libéré récemment la cartographie de son réseau, présumée sous licence
ouverte.
https://www.geredis.fr/Open-data

On y trouve le réseau aérien comme souterrain, ce qui est une bonne
nouvelle au vu du périmètre concerné, plus de 250 communes.

Ce n'est pas tout :
Enedis nous fait également le plaisir de compléter la cartographie déjà
libre depuis avril 2018 avec son réseau souterrain. Ceci sur l'ensemble de
la métropole, sois plus de 400 000 km de réseau portant le total à plus d'1
million de km avec l'aérien.
Le jeu de données des postes est plus complet qu'avant, avec l'ajout des
installations non visibles (la plupart des postes parisiens par exemple).
https://data.enedis.fr/explore/dataset/reseau-souterrain-hta/map/?location=15,45.14656,1.49646=jawg.streets

De ma compréhension et c'est à souligner, de nombreux mois de travail
semblent avoir été nécessaires pour élaborer ces jeux de données avec
l'investissement de plusieurs équipes.
Cela renforce encore la pertinence d'inciter les entreprises à ouvrir leurs
données, si cela était encore à démontrer. Le sujet intéresse et est utile
aux structures qui publient.

Ceci ne serait pas probablement pas possible si la communauté ne
contribuait pas aussi assidûment sur le sujet. Les acteurs concernés ont
bien pris la mesure de notre engagement et de ce que nous pouvions apporter
au pot commun. Ces progrès sont à mettre au crédit de nos efforts à tous.

Bonne fin de semaine

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

Re: [Talk-tr] openstreetmap CN domain and keyword

2019-12-19 Per discussione Roman Neumüller


Bu CN domain konulu mesaj büyük olasılıkla SCAM'dir ve silinir -
Çinlilerin domain sorunları bize ne yani ?

On Wed, 18 Dec 2019 22:59:53 +0300, Jeff Liu   
wrote:



(It's very urgent, please transfer this email to your CEO. Thanks)
This is a formal email. We are the Domain Registration Service company  
in China. Here I have something to confirm with you. On Dec 17, 2019, we  
received an application from Kanghong Ltd requested "openstreetmap" as  
their internet keyword and China (CN) domain names (openstreetmap.cn,  
openstreetmap.com.cn, openstreetmap.net.cn, openstreetmap.org.cn). But  
after checking it, we find this name conflict with your company name or  
trademark. In order to deal with this matter better, it's necessary to  
send email to you and confirm whether this company is your distributor  
or business partner in China?


Best Regards
***
Jeff Liu | Service & Operations Manager
China Registry (Head Office) | 6012, Xingdi Building, No. 1698 Yishan  
Road, Shanghai 201103, China

Tel: +86-02161918696 | Fax: +86-02161918697 | Mob: +86-13816428671
Email: j...@chinaregistry.org.cn
Web: www.chinaregistry.org.cn
***
This email contains privileged and confidential information intended for  
the addressee only. If you are not the intended recipient, please  
destroy this email and inform the sender immediately. We appreciate you  
respecting the confidentiality of this information by not disclosing or  
using the information in this email.



--
katpatuka.org

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

Re: [OSM-talk-fr] Nommage/Numérotation hameaux

Bonjour,

Le 19.12.19 à 13:44, Christian Rogel a écrit :
>> Le 18 déc. 2019 à 22:54, marc marc a écrit :
>> Addr:place :-) remplace addr:street ou associatedStreet lorsque le nom ne 
>> vient pas d'une rue.
> 
> Cela n’est pas très clair. Une rue = un nom de voie formé obligatoirement 
> d’un générique et d’un spécifique ?

non, il faut comprendre "rôle street" au sens osm cad un way avec un tag
highway=primary/secondary/tertiary/residential/living_street/service
que le nom ai un générique/spécifique ou autre n'est pas un critère
pour l'associatedStreet

> Le plus simple est de voir tout nom donné comme officiel, venant ou non d’un 
> nom de lieu que comme il a été voulu, un nom de voie.

ce n'est en rien plus simple d'avoir un associatedStreet
version Christian R., supporté que par lui-même.
cela rendrait juste les données utilisables par tous sauf l'humain.

Si on voulait progresser sur le sujet, il faudrait à mon avis commencer
par améliorer l'associatedStreet actuel dans les éditeurs, avant
d'envisager une proposition hypothétiquement acceptée regroupant
associatedStreet Street et les addr:place

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

Re: [Talk-GB] Disused or empty apartments

2019-12-19 Per discussione Dave F via Talk-GB




On 19/12/2019 02:09, Warin wrote:

On 19/12/19 13:01, Dave F via Talk-GB wrote:

On 19/12/2019 01:41, Andy Townsend wrote:
Aside from this particular question, that's actually a problem that 
happens all the time with things like "amenity=pub; tourism=hotel" -


I'd rather the mapper make a clear choice as they know what is there, 
the render makes a 'best guess'.




Not really. pub & hotel are synonymous but building=yes (which 
indicates it's operational) is antonymous to disused:building



Some pubs are not hotels - no accommodation.


I was referring to Andy's example where both tags are on the same object



I have taken to mapping the building as a close way with building=* 
and then adding separate nodes for pub and another for the hotel if it 
has that.

Note I am not consistent in this (but I should be)!


I have done similar, but never felt it an ideal situation. it ends up 
with three detached objects representing one establishment. Where would 
you add the FHRS:ID tag?


I try & do 'the duck test'. I ask 'what is it most known for' If it's a 
pub, which happens to have a few rooms, then amenity=pub, 
accommodation=yes, & alternatively tourism=hotel, bar=yes


Cheers
DaveF

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

[Talk-GB] No Through Road Ahead

2019-12-19 Per discussione Martin Wynne


How to tag this road?

 https://goo.gl/maps/B4kUxoR83ej9JXWQ8

There is no actual barrier, just a very sharp corner.

Thanks.

Martin.

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

Re: [OSM-talk-fr] Nommage/Numérotation hameaux (Était : Re: Joli noms de rues)

2019-12-19 Per discussione Бондаренко Кирилл

Les génériques sont fréquents en France mais pas systématiques. Et bon
nombre de "génériques" ne correspondent à aucun standard car ils sont fans
une variété régionale ou locale ou s'écrivent en suffixes et non en
préfixe. et pas qu'en métropole non plus. Allez voir en Bretagne, en
Alsace, au Pays Basque, en Corse, en pays catalan ou occitan... Les
génériques standards sont surtout dans les zones très urbanisées, où le
loti est aligné et pas dispersé mais relié au réseau général par des
chemins ruraux ou privés sans noms et pas toujours avec un numéro de
référence officiel.

D'ailleurs le FANTOIR lui-même n'indique aucun générique codé dans ces cas
là, la forme complète (parfois abrégée ou tronquée si trop longue) est
reprise telle quelle (en capitales non accentuées malheureusement, héritage
du passé où l'ASCII-US régnait encore, même en France quand il y avait
pourtant eu unen version ISO 646-FR normalisée par l'AFNOR, tombée depuis
il y a longtemps en désuétude avec ISO 8859-1 puis Unicode où les accents
auraient dût être présents (le FANTOIR pourtant fournit un terme générique
de recherche, ce champ est lui aussi en désuétude avec les méthodes de
recherche actuelles en texte plain et la normalisation des algorithmes de
collation: la conception du FANTOIR est donc surtout basée sur les
préconisation de la Poste pour les adresses imprimées sur les courriers
selon les vielles normes de l'UPU, alors que la plupart des entrées, issues
du Cadastre historique qui lui avait bien les accents sur ses planches, ne
sont même pas valides pour la Poste qui a plutôt fait ce qu'elle a voulu
sans concertation).

On se demande où est la compétence communale si on leur impose ce vieux
format FANTOIR pour la remontée des noms. Il faut croire que c'est
l'informatique de l'adminsitration qui est très en retard et se base encore
sur des vieux logiciels des années 1960-1970 et une consultation sur des
terminaux texte ou téléimprimeurs et l'usage immodéré du FAX et de la
resaisie pendant pas mal d'année (la resaisie continue encore, même
aujourd'hui avec les portails Internet pour les communications à
l'admisnitration, j'en sais quelquechose: on a beau remplir les formulaire
avec son nom exact pour une demande de papier d'identités ou cocher les
bonnes cases, ce n'est toujours pas ce qui est renvoyé ensuite et on je
retrouve avec 5 identitiés différentes d'une adminiqtration à l'autre et
aucune qui correspond à mon état-civil que pourtant on me demande de
justifier à chaque fois, et ensutie les mêmes admisnitrations qui se
mettent à me redemander de justifier mon identité ou prétendent que ce
n'est pas moi, ça finit par des démarches par recommandé: l'Internet n'a
pas simplifié les choses, j'aiu surtout l'impression que c'est une
surcouche qui s'est ajoutée...)
Le jeu. 19 déc. 2019 à 13:45, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
>
> > Le 18 déc. 2019 à 22:54, marc marc  a écrit :
> >> Le 18 déc. 2019 à 22:48, deuzeffe  a écrit :
> >>
> >> je n'arrive pas à décider quelle est la moins mauvaise méthode.
> >
> > Addr:place :-) remplace addr:street ou associatedStreet lorsque le nom
> ne vient pas d'une rue.
>
> Cela n’est pas très clair. Une rue = un nom de voie formé obligatoirement
> d’un générique et d’un spécifique ? Pourquoi ne pas considérer comme valide
> un odonyme dont le générique est absent ?
> D’autant que, la présence de noms en langue autre que le français ne peut
> génèrer qu’une multitude de faux positifs.
> Le plus simple est de voir tout nom donné comme officiel, venant ou non
> d’un nom de lieu que comme il a été voulu, un nom de voie.
>  »Address:place« .  accompagné d'un numéro paraît donc une fantaisie peu
> utile.
> Christian Q. a mentionné un mot-directeur. A quoi fait-il référence ?
>
> Christian R.
>
> ___
> 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] Nommage/Numérotation hameaux (Était : Re: Joli noms de rues)

2019-12-19 Per discussione osm . sanspourriel


Le 19/12/2019 à 13:44, Christian Rogel -
christian.ro...@club-internet.fr a écrit :


D’autant que, la présence de noms en langue autre que le français ne peut 
génèrer qu’une multitude de faux positifs.


Non, par rue de associatedStreet on entend highway=xxx, peu importe que
ce soit une rue, route, peu importe qu'elle s'appelle Rue, Chemin, Hent
ou Strasse.

Le problème pour utiliser associatedStreet pour autre chose que des
highway c'est qu'on n'a pas la même topologie: qu'un côté on a du
filaire (highway=) et de l'autre du surfacique (place d'une relation) ou
du ponctuel (place seul ou comme admin center).

Si tu acceptes du surfacique sur du associatedStreet pour une place je
vous plusieurs problèmes :

- une rue associée, c'est une rue, associatedHighway aurait été un
meilleur nom mais bon. Si tu mets du surfacique avec un tel nom tu sous
entend area:highway c'est à dire la bande de roulement et non la voirie
plus les numéros d'adresses (plus les parcelles accessibles depuis cette
route en direct).

- pour une place, le surfacique c'est l'enveloppe complète à savoir les
rues mais aussi les terrains accessibles depuis ces rues.

Si on mélange deux concepts pour un même schéma on va chercher les
embrouilles. Même si on pourrait s'en sortir en mettant des membres
ayant pour role boundary pour délimiter une place=, suaf que ça
doublonnerait les relations type=boundary.

C'est pourquoi je propose d'utiliser les relations boundary=place pour
obtenir l'équivalent de associatedStreet : même modélisation des membres
house mais autres attributs en tête (tout en partageant par exemples
*name* et ref:FR:FANTOIR).

Ça permet de factoriser comme associatedStreet sans faire
d'associatedStreet une chimère.

Note : pour les places sans zonage bien défini - heu si c'est numéroté
c'est bien que la limite est assez nette - on peut ne mettre aucun way
pour définir le périmètre et se contenter d'un nœud label pour un indice
de l'endroit où afficher la place.

 »Address:place« .  accompagné d'un numéro paraît donc une fantaisie peu utile.

Ça permet de dire que le numéro correspond à une adresse dans un
lieu-dit. Je ne vois pas ce que ça a de fantaisiste.

Ce qui est fantaisiste comme dit Christian Quest c'est de numéroter des
hameaux plutôt que de nommer des voies et numéroter ces voies.

Mais ça, OSM n'y peut pas grand chose.

Jean-Yvon

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

[Talk-GB] Fw: Appeal for Help - Amending a Route Relation - NCN Route 51

2019-12-19 Per discussione Peter Neale via Talk-GB

Many thanks to @Richard Fairhurst, @Warin and @ Paul Berry for their 
encouragement and help.  I will have a go at making the amendments using the iD 
Editor.  
I'm not sure how soon that will happen, though, as I hear that Christmas is 
coming and Grandads like me are meant to spend time with their families, not on 
the computer.
Before I start, I have one more question:
@Richard Fairhurst said, "It's more important that the route is unambiguous,  
i.e. the member ways all join to form a single route without unnecessary 
branches and loops."
However, the Sustrans map shows some dead-end branches (presumably to link into 
other infrastructure, such as roads and other cyclepaths).  There are 2 that 
are relevant here; one is marked on the ground (probably because it was part of 
the old route), but the other is not.  I do not propose to include the unmarked 
one, but what about the one that is marked?  Should I include it, or not?  
Regards,Peter


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

Re: [Talk-GB] barrier=kerb on highways may be blocking OSRM (Car) routing

2019-12-19 Per discussione James Derrick


Hi Edward,

On 18/12/2019 16:31, Edward Catmur via Talk-GB wrote:
Further to this - if you want to look for barrier=kerb + 
highway=crossing nodes in your area, which may be disrupting routing, 
the Overpass query is node["barrier"="kerb"]["highway"="crossing"] : 
https://overpass-turbo.eu/s/P5YJames


Brilliant - there is a rash of barrier=kerb in North Tyneside 
(Cullercoates and Whitley Bay), which rather explains the original 
routing issues.


Time to fire up JOSM...

Thanks,


James
--
James Derrick
li...@jamesderrick.org, Cramlington, England
I wouldn't be a volunteer if you paid me...
https://www.openstreetmap.org/user/James%20Derrick


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

Re: [OSM-talk] State of the Map Baltics 2020

Hi Ilya, Is it possible to publish *exact address* of the conference? I guess it will take place in university of Latvia (main building?), but just to be on the safe side :)  Kirill aka zkir.13.12.2019, 10:06, "Ilya Zverev" :Hi,Hard to believe, but the conference that we had once in 2013, has got its second coming! Announcing the perfect event for these living in Eastern Europe, or who can afford flying AirBaltic:State of the Map Baltics 2020 will take place in Riga, Latvia, on 6th of March 2020. It will be a part of a bigger event, Baltic GIT Conference (no relation to the version management system).We would be delighted to see you as a participant or, even better, to have you on the stage. Please register at:http://2020.sotm-baltics.org/The language is English, the sea and beaches are near, and the weather should be fine. Once again, that is a great chance to meet mappers from the less represented countries, but without travelling to the far edge of Africa.More news to follow — and see you there!Ilya___talk mailing listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [OSM-dev] tagtransform for OSM - An effort to make tagging and using OSM data easier; bridging different worlds together

2019-12-19 Per discussione Sören Reinecke via talk

Hello,

I think I need to provide an overview of tagtransform for you to
understand what I want to achieve and to get the idea of bridging. An
update of the repository with better explanation will follow. Some
things changed and some users inspired me so I forgot to update the
README.md accordingly.

Tagtransform specification: (Need ideas to add to the specification,
read here the specification and here you get to know how to contribute)
- The specification enables the convertion from one format to another
by inventing a language that acts as a connection point. This is useful
for offline usage of the rules in the format the app developer can
better work with.
- Bridge between languages
  - e.g. JOSM xml <--> tagtransform specification <--> iD json
  - Data Item database <--> tagtransform specification <--> JOSM xml
- You can contribute to tagtransform
  - by improving the specification
  - by developing scripts that use the specification
  - by developing converters that convert tagtransform specification to
other formats like JSOM xml

Role of validators:
- Validators can take the data from Data Items to create validation
rules
- and can also inspire the Data Item OSM Community by providing them
with validation suggestions.

Role of editors:
- Editors can take the data from Data Items to automatically transform
deprecated tags and to discard discardable tags.
- For offline usage they can fetch data from Data Items and can
transform them to tagtransform specification.
- Recommend a specified POI tagging through presets or automatically
transforming wrong used tags like deprecated ones to new ones.

OSM Data Item Community: (important because tagtransform will use data
they create)
- They have the necessary infrastructure to host key/tag data and they
have already a bunch of these inclusive validation rules and usage
rules.
- They're mappers and understand how keys/tags are used and can
transfer that to meta sphere used by data customers, editors and
validators.
- Go to the Data Item Wikipage to get what it is all about and how to
contribute to Data Items.

Bots/Scripts: (Please do not work on unless we make the specification
production-ready)
- Can be used to query Data Item database for preprocessing data for
later use like offline usage or data analysation at larger scale
- through converting received data to tagtransform specification.
- You can contribute to tagtransform by developing scripts that make
use of the Data Item database of OSM Wiki by fetching them and
converting them to tagtransform specification.

I hope this helps

Cheers

Sören Reinecke alias ValorNaram

-Original Message-
From: Sören Reinecke via dev 
Reply-To: Sören Reinecke 
To: d...@openstreetmap.org
Subject: [OSM-dev] tagtransform for OSM - A effort make tagging and
using OSM data easier; bridging different worlds together
Date: Thu, 05 Dec 2019 15:50:04 +0100

Hey all,

I currently write a specification for tranforming tags in OpenStreetMap
to make life of data customers easier. Different tagging schemes have
emerged since the existence of OpenStreetMap, same are existing in
parallel and a newer one deprecated an old one. Data customers without
knowing the OSM community much get lost. This project aims to help
developers who want to take advantage of the OpenStreetMap great
database which is by the way a brilliant project. This project can also
help to make tagging in OSM more orthogonal and more hassle free.

I saw conflicting interests between OSM community, OSM developers like
the iD developers and data customers. A renderer might need data in
another way as the community contributes. The community might need
another tagging scheme than a renderer. I thought how we can resolve
this, how we can get all sites on "one table" and that is the idea I
had come up with:

A more readable version can be found here: 
https://github.com/ValorNaram/transformation-table-osmtags/blob/master/README.md
and the principles can be found at 
https://github.com/ValorNaram/transformation-table-osmtags/blob/master/principles.md



Example 1: They want to have the phone number of a POI. There are some
problems with this:

1. They need to know both contact:phone and phone to get them all.
2. They need to support them both.
3. They need to remove one in case both keys are mapped on one POI.
This really happens, see http://overpass-turbo.eu/s/OI2.

Example 2: They want to know how many POI's have changing tables
(general: facilities for changing a nappy of a baby). There are some
problems with this too:

1. They need to know both changing_table and the deprecated diaper
to get them all.
2. They need to support them both. Difficult because they're highly
different tagging schemes.
3. They need to remove one in case both keys are mapped on one POI.
This really happens, see http://overpass-turbo.eu/s/OI5.

Example 3: They want to develop a mapping tool and want to correct
wrong typed in tags. There are some problems with

Re: [OSM-talk-fr] Nommage/Numérotation hameaux (Était : Re: Joli noms de rues)

2019-12-19 Per discussione Christian Rogel



> Le 18 déc. 2019 à 22:54, marc marc  a écrit :
>> Le 18 déc. 2019 à 22:48, deuzeffe  a écrit :
>> 
>> je n'arrive pas à décider quelle est la moins mauvaise méthode.
> 
> Addr:place :-) remplace addr:street ou associatedStreet lorsque le nom ne 
> vient pas d'une rue.

Cela n’est pas très clair. Une rue = un nom de voie formé obligatoirement d’un 
générique et d’un spécifique ? Pourquoi ne pas considérer comme valide un 
odonyme dont le générique est absent ?
D’autant que, la présence de noms en langue autre que le français ne peut 
génèrer qu’une multitude de faux positifs.
Le plus simple est de voir tout nom donné comme officiel, venant ou non d’un 
nom de lieu que comme il a été voulu, un nom de voie.
 »Address:place« .  accompagné d'un numéro paraît donc une fantaisie peu utile.
Christian Q. a mentionné un mot-directeur. A quoi fait-il référence ?

Christian R.

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

Re: [OSM-talk-be] Mapillary

2019-12-19 Per discussione Georges De Gruyter

Blauwe lijnen zijn je eigen foto’s, Guy.


> Op 19 dec. 2019, om 13:14 heeft Guy Vanvuchelen  
> het volgende geschreven:
> 
> Kan iemand me vertellen hoe het komt dat ik bepaalde stukken uit een  
> fotoserie niet zie op Mapillary en wel in JOSM. (zie bijlage)
> Wat is het verschil tussen blauw en groen?
>  
> Guy Vanvuchelen
>  
>  
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be 
> 
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Mapillary

2019-12-19 Per discussione Jo

Zou het kunnen dat blauw de foto's zijn die je nog niet hebt doorgestuurd
naar Mapillary?

Jo

On Thu, Dec 19, 2019 at 1:15 PM Guy Vanvuchelen 
wrote:

> Kan iemand me vertellen hoe het komt dat ik bepaalde stukken uit een
>  fotoserie niet zie op Mapillary en wel in JOSM. (zie bijlage)
>
> Wat is het verschil tussen blauw en groen?
>
>
>
> Guy Vanvuchelen
>
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] Noms de rue, osmose et bano V2

2019-12-19 Per discussione Vincent de Château-Thierry

Bonjour,

> De: "Vincent Bergeot" 
> 
> Oui il va falloir aller voir sur le terrain pour départager mais je
> me demande si ces outils qualités se parlent et surtout comment ils
> se parlent ? Entendu par là que j'ai l'impression que la qualité de
> l'un n'est pas exploité par l'autre et que la qualité de l'autre
> n'est pas exploité par l'un :D
> 
> C'est peut-être une évidence évidente sachant que les sources de
> "comparaisons sont différentes" mais cela m'intrigue :)

Non rien d'évident :).
Je ne sais pas ce qu'Osmose vient piocher dans BANO, a fortiori dans quelle 
version de BANO. Dans l'autre sens BANO n'interroge pas Osmose comme source ou 
comme intermédiaire vers d'autres sources, la démarche de comparaison avec le 
Cadastre et Fantoir se fait en direct.

vincent

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

[OSM-talk-be] Mapillary

2019-12-19 Per discussione Guy Vanvuchelen

Kan iemand me vertellen hoe het komt dat ik bepaalde stukken uit een
fotoserie niet zie op Mapillary en wel in JOSM. (zie bijlage)

Wat is het verschil tussen blauw en groen?

 

Guy Vanvuchelen

 

 

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

Re: [OSM-talk-fr] Fwd: [osm-grenoble] Projet Europeen de l'Eau/European Water Project - Introduction

Bonjour,

Le 19.12.19 à 11:33, European Water Project a écrit :
> Je viens de m'inscrire sur cette liste de distribution, donc je n'ai pas
> pu répondre à l'email précèdent sur le sujet.   

bienvenue !
les archives te permettent de lire ce qui s'est dit précédemment.
https://lists.openstreetmap.org/pipermail/talk-fr/2019-December/095604.html
tu peux facilement répondre (mais sans citation automatique) en cliquant
sur la 2ieme ligne de l'archive, celle contenant l'email de l'expéditeur
(il contient aussi l'id du message pour ceux qui ont un client qui
l'utilise).

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

Re: [OSM-talk-fr] Noms de rue, osmose et bano V2



> Le 19 déc. 2019 à 12:03, Vincent Bergeot  a écrit :
> 
> je me demande si ces outils qualités se parlent et surtout comment ils se 
> parlent ?

Ils se parlent mais la version bano v2 n'est pas encore déployée/utilisée 
partout. D'où une partie des différences entre les outils.
Ils se parle via bdd (pour le rendu) et https (pour la remontée osmose)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nommage des bâtiments scolaires / universitaires complexes

2019-12-19 Per discussione Arnaud Champollion


Le 18/12/2019 à 22:01, Romain MEHUT a écrit :


Cet exemple des SEGPA me gêne aussi depuis pas mal de temps car ce 
sont des structures rattachées à des collèges et  donc identifier ces 
SEGPA avec amenity=school fait doublon avec les collèges déjà en 
amenity=school.


Je n'arrive pas à trouver, pour Digne-les-Bains, sur 
https://www.education.gouv.fr/annuaire , de code UAI (RNE) pour la SEGPA 
rattachée au Collège Gassendi.


Comme je passe devant assez souvent, j'essaierai de voir si son nom 
apparaît à l'entrée à côté du nom du collège.



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

Re: [OSM-talk-fr] Noms de rue, osmose et bano V2

Une analyse Osmose ne pourrait pas vérifier les lettres-clé (en calculant
avec le code direction=0 non indiqué, sauf Paris, Nord, Hauts-de-Seine et
Bouches-du-Rhône : je note que les lettres-clé sont souvent mal lues. En
vérifiant la clé, on peut détecter les chiffres redoublés/inversés ou
confondus (8 et B confondus dans le type de voie en 6e position, ou 0 et 8
par exemple dans le numéro de voie, ou bien I (incorrect) et L dans la
lettre-clé).
La validité du FANTOIR est possible avant toute tentative de rapprochement.

Le jeu. 19 déc. 2019 à 12:30, Philippe Verdy  a écrit :

> Une autre carte montrant des codes FANTOIR de format incorrect (il y a
> bien 10 caractères, mais pas les bons chiffres/lettres (par exemple un
> chiffre ou I,O,Q est présent dans le 10e caractère de la clé). Les cas
> fréquents trouvés concerne la conservation du code direction en 3e
> position, mais la suppression de la lettre-clé en 10e position.
>
> https://overpass-turbo.eu/s/P79
>
>
> Le jeu. 19 déc. 2019 à 12:03, Vincent Bergeot  a
> écrit :
>
>> Bonjour,
>>
>> je creuse un peu en ce moment autour des noms de rue et je m’interroge
>> sur les liens, voire non-liens entre osmose et banov2 !
>>
>> Je prends un exemple (et j'en ai croisé d'autres) :
>>
>>-
>>
>> http://osmose.openstreetmap.fr/fr/map/#zoom=18=43.439932=-1.584408=7170=1%2C2%2C3==
>>   - il me propose le nom à modifier et une ref fantoir (641250131)
>>-
>>http://dev.cadastre.openstreetmap.fr/fantoir/index.html#insee=64125=3
>>   - j'ai le rapprochement entre FANTOIR et OSM, sur le nom mais sur
>>   un autre code (64125B051K)
>>
>> Oui il va falloir aller voir sur le terrain pour départager mais je me
>> demande si ces outils qualités se parlent et surtout comment ils se parlent
>> ? Entendu par là que j'ai l'impression que la qualité de l'un n'est pas
>> exploité par l'autre et que la qualité de l'autre n'est pas exploité par
>> l'un :D
>>
>> C'est peut-être une évidence évidente sachant que les sources de
>> "comparaisons sont différentes" mais cela m'intrigue :)
>>
>> à plus
>>
>> --
>> Vincent Bergeot
>>
>>
>>
>> ___
>> 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] SPAM, Re: Nommage des bâtiments scolaires / universitaires complexes

2019-12-19 Per discussione Arnaud Champollion


Le 19/12/2019 à 08:21, marc marc a écrit :

Tu fais comment quand le même établissement est à la fois une crèche,
une maternelle (selon l'heure de la journée), un centre de loisirs:



Un même établissement ne peut pas être crèche et maternelle. Si l'on 
voit ça, ce sont toujours deux établissements séparés et chacun peut 
donc avoir son tag spécifique.


En revanche, école (maternelle ou autre) et centre de loisirs (centres 
"aérés") partagent parfois, dans certaines villes les mêmes locaux sur 
des jours différents. Dans ce cas je dirais amenity=school sur l'emprise 
parcellaire de l'école, et un noeud community_centre=youth_centre (je ne 
suis pas certain que ce tag soit le bon mais je n'ai pas trouvé mieux - 
d'ailleurs à Digne le Centre de Loisirs de la Sympathie n'a pour 
l'instant pas d'attribut).


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

Re: [OSM-talk-fr] Noms de rue, osmose et bano V2

Une autre carte montrant des codes FANTOIR de format incorrect (il y a bien
10 caractères, mais pas les bons chiffres/lettres (par exemple un chiffre
ou I,O,Q est présent dans le 10e caractère de la clé). Les cas fréquents
trouvés concerne la conservation du code direction en 3e position, mais la
suppression de la lettre-clé en 10e position.

https://overpass-turbo.eu/s/P79


Le jeu. 19 déc. 2019 à 12:03, Vincent Bergeot  a
écrit :

> Bonjour,
>
> je creuse un peu en ce moment autour des noms de rue et je m’interroge sur
> les liens, voire non-liens entre osmose et banov2 !
>
> Je prends un exemple (et j'en ai croisé d'autres) :
>
>-
>
> http://osmose.openstreetmap.fr/fr/map/#zoom=18=43.439932=-1.584408=7170=1%2C2%2C3==
>   - il me propose le nom à modifier et une ref fantoir (641250131)
>-
>http://dev.cadastre.openstreetmap.fr/fantoir/index.html#insee=64125=3
>   - j'ai le rapprochement entre FANTOIR et OSM, sur le nom mais sur
>   un autre code (64125B051K)
>
> Oui il va falloir aller voir sur le terrain pour départager mais je me
> demande si ces outils qualités se parlent et surtout comment ils se parlent
> ? Entendu par là que j'ai l'impression que la qualité de l'un n'est pas
> exploité par l'autre et que la qualité de l'autre n'est pas exploité par
> l'un :D
>
> C'est peut-être une évidence évidente sachant que les sources de
> "comparaisons sont différentes" mais cela m'intrigue :)
>
> à plus
>
> --
> Vincent Bergeot
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Trunk VS primary,

2019-12-19 Per discussione Mike N


On 12/17/2019 10:19 PM, Evin Fairchild wrote:
some US routes are more important than others and lumping them all as 
primary doesn???t make any sense;


The arguments here about relative importance of parallel routes makes 
sense.


  Some massive changes such as in 
https://www.openstreetmap.org/changeset/78620805 are raising roads which 
have no other major choices, but are apparently just because they are 
the most important.


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

[OSM-talk-fr] Noms de rue, osmose et bano V2

2019-12-19 Per discussione Vincent Bergeot


Bonjour,

je creuse un peu en ce moment autour des noms de rue et je m’interroge 
sur les liens, voire non-liens entre osmose et banov2 !


Je prends un exemple (et j'en ai croisé d'autres) :

 * 
http://osmose.openstreetmap.fr/fr/map/#zoom=18=43.439932=-1.584408=7170=1%2C2%2C3==
 o il me propose le nom à modifier et une ref fantoir (641250131)
 * http://dev.cadastre.openstreetmap.fr/fantoir/index.html#insee=64125=3
 o j'ai le rapprochement entre FANTOIR et OSM, sur le nom mais sur
   un autre code (64125B051K)

Oui il va falloir aller voir sur le terrain pour départager mais je me 
demande si ces outils qualités se parlent et surtout comment ils se 
parlent ? Entendu par là que j'ai l'impression que la qualité de l'un 
n'est pas exploité par l'autre et que la qualité de l'autre n'est pas 
exploité par l'un :D


C'est peut-être une évidence évidente sachant que les sources de 
"comparaisons sont différentes" mais cela m'intrigue :)


à plus

--
Vincent Bergeot


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

Re: [OSM-talk-fr] Nommage/Numérotation hameaux

2019-12-19 Per discussione osm . sanspourriel



Le 18/12/2019 à 22:47, deuzeffe - opensm@deuzeffe.org a écrit :

même si les teutons l'ont déclarée deprecated


Je corrige : les Allemands n'ont pas déprécié les associatedStreet, ils
ont déprécié les associatedStreet _en Allemagne_.

Comme OSM supporte les deux modélisations ça n'a aucune influence pour
la France.

Simplement un contributeur de poids en moins pour demander aux éditeurs
de prendre en charge notre modélisation favorite.

Si tu veux ne pas te faire ressembler à un sapin de Noël, tu le fais "à
l'allemande" c'est à dire que tu mets sur chaque nœud adresse non seulement

addr:housenumber


mais aussi

addr:place 

Du coup c'est lourd, mais Nominatim fonctionne et Osmose ne dit rien.

> Ça me donne l'impression que lors de la discussion pour créer le type
de relation associated street, seule a prévalu l'organisation standard
des villes occidentales...

+1, hélas. On fait un associatedPlace? On enrichit les relations


type=boundary
boundary=place

avec des rôles house ?

Jean-Yvon


Jean-Yvon

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

[OSM-talk-fr] Fwd: [osm-grenoble] Projet Europeen de l'Eau/European Water Project - Introduction

2019-12-19 Per discussione European Water Project

Bonjour,



Je viens de m'inscrire sur cette liste de distribution, donc je n'ai pas pu
répondre à l'email précèdent sur le sujet.



Je m’appelle Stuart Rapoport. Je fais partie d'une association
StopEmbouteillage qui a lutté à Divonne les Bains avec succès contre un
projet d'embouteillage de 400 millions de bouteilles d'eau en PET par an
destinées à l'Asie. Voici la page FB de notre  association.
https://www.facebook.com/stopembouteillage/



Pour peupler les fontaines sur la carte d'European Water Project, nous
faisons tourner un script en nodejs qui extrait les données d'OSM par l'API
Overpass et celles de Wikidata par l'API SPARQL.   Nous n’avons pas de
données propres à nous et nous demanderons à tous d’ajouter et maintenir la
base de données des fontaines directement dans OSM (et Wikimedia Commons).
Notre projet est 100% open data.



Nous avons écrit des instructions destinées au public pour décrire comment
ajouter et éditer des fontaines dans OpenStreetMap et comment créer des
photos dans Wikimedia Commons et les lier aux fontaines dans
OpenStreetMap.



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




Les instructions ne sont qu'en anglais pour l'instant, mais si vous avez
des suggestions pour les rendre plus compréhensibles, nous sommes à
l'écoute surtout avant de les traduire dans d'autres langues. Nous les
traduirons en français d'ici trois semaines.





Nous lançons notre projet début janvier. Voici un lien vers la PWA que nous
développons et que vous pouvez télécharger sans passer par le Google ou
Apple app store. . https://europeanwaterproject.org



Bien cordialement,



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

Re: [Talk-GB] Appeal for Help - Amending a Route Relation - NCN Route 51

2019-12-19 Per discussione Paul Berry

This is all perfectly doable in iD (which I've used to map hundreds of
relations) so be bold.

Give it a go, mark your changeset for review if you want, and—after
publishing—make use of tools like the excellent http://ra.osmsurround.org which
will show any gaps or oddities with your relation.

Regards,
*Paul*

On Thu, 19 Dec 2019 at 10:12, Warin <61sundow...@gmail.com> wrote:

> On 19/12/19 19:49, Richard Fairhurst wrote:
> > Peter Neale wrote:
> >> I would love to amend the Route Relation, but have no idea how to
> >> go about it.
> > Brilliant. Thanks for taking this on!
> >
> > You can do it from iD - no particular need to use JOSM for this.
> Essentially
> > the trick is, for each way that needs to be removed from the relation,
> > select it, scroll down to the bottom of the tags panel, find where it
> says
> > 'NCN 51', and click the rubbish bin. Then, for each way that needs to be
> > added, select it, click '+' at the bottom, and start typing "NCN 51".
> Select
> > it and the route will be added.
> >
> > Don't worry about ordering... the majority of bike routes in the UK
> aren't
> > ordered. If someone desperately wants it to be ordered they can fix it
> > themselves afterwards. It's more important that the route is unambiguous,
> > i.e. the member ways all join to form a single route without unnecessary
> > branches and loops.
>
> It is 'nice' if it is ordered. It does show the elevation profile in
> waymarked trails well when ordered.
>
> Peter .. when your finished I'll order it and go over it for anything that
> I think might be wrong/improved.
> Feel free top disagree with my ideas .. I am not always correct!
> Just leave a message here, I should see it (eventually). Same if you have
> any questions/problems .. ask and you'll have a few answers.
>
> I'm not an iD user so cannot help there.
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Appeal for Help - Amending a Route Relation - NCN Route 51

2019-12-19 Per discussione Warin


On 19/12/19 19:49, Richard Fairhurst wrote:

Peter Neale wrote:

I would love to amend the Route Relation, but have no idea how to
go about it.

Brilliant. Thanks for taking this on!

You can do it from iD - no particular need to use JOSM for this. Essentially
the trick is, for each way that needs to be removed from the relation,
select it, scroll down to the bottom of the tags panel, find where it says
'NCN 51', and click the rubbish bin. Then, for each way that needs to be
added, select it, click '+' at the bottom, and start typing "NCN 51". Select
it and the route will be added.

Don't worry about ordering... the majority of bike routes in the UK aren't
ordered. If someone desperately wants it to be ordered they can fix it
themselves afterwards. It's more important that the route is unambiguous,
i.e. the member ways all join to form a single route without unnecessary
branches and loops.


It is 'nice' if it is ordered. It does show the elevation profile in waymarked 
trails well when ordered.

Peter .. when your finished I'll order it and go over it for anything that I 
think might be wrong/improved.
Feel free top disagree with my ideas .. I am not always correct!
Just leave a message here, I should see it (eventually). Same if you have any 
questions/problems .. ask and you'll have a few answers.

I'm not an iD user so cannot help there.


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

Re: [OSM-talk-fr] Idée folle : changer building=service en building=utility lorsqu'applicable



Le 19 déc. 2019 à 10:05, Yves P.  a écrit :

>> Je ne saisis pas comment tu veux d'écrire "une fois pour toute" quelque 
>> chose qui varie selon les cas (armoire de rue, bâtiment dit de service, 
>> poteau, pièce technique).
>> Pourrais-tu donner 2 exemples Switch dans une armoire de rue et dans une 
>> pièce multi-équipements) ?
> Je ne parlais pas de tous les tags, mais par exemple des man_made=*
> 
> Tu peux décrire (une fois pour toute) que power=switch n’est possible que 
> pour street_cabinet=power ou power=pole…

Tu peux très bien d'écrire qu'un Switch n'est possible qu'en combinaison avec X 
autres tags (encore qu'en l'occurrence il peux aussi être dans une pièce Tage 
séparément donc aucun tag sur l'objet). Mais cela n'empêche que j'aimerai bien 
que tu donnes les tags des 2 exemples, il faudra bien un tag pour dire que ce 
Switch la est par exemple dans une armoire alors que tel autre non
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Disused or empty apartments prior to demolition




17 Dec 2019, 17:58 by silentspike...@gmail.com:

> The `building` tag actually specifies the original purpose or form of the 
> building - it just happens that this usually aligns with the current use. As 
> such, I think it's fine to leave them tagged as `building=apartments`.
>
I would do exactly this way and add 
disused=yes.

IMHO mapping closed convenience shop where just
sign/visible interior remain as
shop=convenience + disused=yes
is a mistake as it is no longer a shop.
disused:shop=convenience would make more sense
But for example landuse=quarry that is no
longer used but is still 
a clearly visible object is still a quarry
so in this case landuse=quarry + disused=yes is preferable

Buildings seems to fit the second case,
building tag describes building construction,
not building use.

Building constructed as a church,
now used as a warehouse but still
clearly constructed as a church is building=church

Church building that is now unused
is building=church

Apartments building that is now unused
is building=church.
>
> See: > https://wiki.openstreetmap.org/wiki/Key:building:use> . Interestingly 
> that wiki page points to the lifecycle prefix page for the case of disused 
> buildings, but I'd say feel free to use `building:use=disused` to explicitly 
> tag them for future mappers to see.
>
> On Tue, Dec 17, 2019 at 3:22 PM Jez Nicholson <> jez.nichol...@gmail.com> > 
> wrote:
>
>> Change it to building=yes + disused:building=apartments ?...it's still a 
>> building, but the original use is now disused?
>>
>> - Jez
>>
>> On Tue, 17 Dec 2019, 14:51 Gareth L, <>> o...@live.co.uk>> > wrote:
>>
>>> There are some tower blocks near me which have been emptied of residents 
>>> ahead of eventual demolition of the buildings. They’re not coming back into 
>>> use due to issues with their construction. 
>>> http://www.mapillary.com/map/im/lzDlWfY8iYo2cUVmO1FNmQ/photo>>>  They’re 
>>> boarded up to secure them in the interim.
>>>
>>> All the guidance I can find on the abandoned or disused tags are to leave 
>>> the building as defined but to use abandoned/disused prefix on the amenity. 
>>>
>>> These didn’t have an amenity though. They do still exist on the ground, but 
>>> no longer function as apartments.
>>>
>>> I’d like to use construction style tagging, but it doesn’t feel quite right 
>>> looking at all examples I’ve found. e.g.
>>> Building=disused
>>> Disused=apartments
>>>
>>> What have you used for buildings which are awaiting demolition, or are 
>>> undergoing a protracted demolition process but are not amenities?
>>>
>>> Gareth
>>> ___
>>>  Talk-GB mailing list
>>>  >>> Talk-GB@openstreetmap.org
>>>  >>> https://lists.openstreetmap.org/listinfo/talk-gb
>>>
>> ___
>>  Talk-GB mailing list
>>  >> Talk-GB@openstreetmap.org
>>  >> https://lists.openstreetmap.org/listinfo/talk-gb
>>___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] barrier=kerb on highways may be blocking OSRM (Car) routing