date:20200901

J'aurais tendance aussi à faire de ces courées des rues à part (pour leurs
propres adresses habitables, pas pour leur simple accès comme le 76 rue du
Caire, qui continue à faire partie de la rue du Caire mais n'est pas une
habitation ou une réelle adresse de résidence, leur seul "intérêt étant
leur porte d'accès (s'il y en a une).

Du moins si ces courées ont un statut public officialisé dans le cadastre
ou FANTOIR, ce sont des "rues" par elle-même même si elles sont uniquement
piétonnes et pas accessibles aux véhicules (hors 2 roues mais pas pour y
rouler).

Si la courée est privée (c'est une copropriété) alors ces adresses internes
sont comme des numéros d'appartement dans un même immeuble ou un ensemble
d'immeubles autour d'une partie commune: c'est une numérotation interne
(j'ai vécu dans un tel immeuble avec des parties communes dont une cour
partagée en copropriété aussi par deux maisons individuelles non
accessibles directement depuis la voie publique mais ayant un droit de
passage permanent par l'immeuble et leurs boites au lettres étaient
groupées dans l'immeuble avec celles des appartement, le courrier ne
mentionnait qu'un seul numéro, les numéros de porte/d'appartement étaient
optionnels, ce qui compte c'était le nom du destinataire sur la boite au
lettre mentionnant ensuite l'étage ou l'emplacement via la cour commune)

Sur une adresse postale, mettre les deux lignes c'est comme indiquer le
chemin à suivre avec un point intermédiaire sur une autre rue que le point
d'arrivée. Mais ça ressemble tout autant à mentionner un numéro
d'appartement dur une ligne supplémentaire avant l'adresse sur la rue
publique: le critère de distinction semble être la présence ou pas dans le
FANTOIR, qui ne détaille pas en principe les copropriétés (mais il peut y
avoir d'anciennes voies publiques privatisées en copropriétés (avec
l'accord des propriétaires et après accord et vente par la collectivité, et
la formation appropriée de la structure légale de gestion de la copropriété
qui sera taxée) souhaitant sécuriser un accès et aménager des installations
communes protégées et entretenues (cour, jardin, local technique, garage,
etc.)

Le mar. 1 sept. 2020 à 22:23,  a écrit :

> J'aurais tendance à voir ça comme une rue à part.
>
> Mais pour la double adresse, addr:full est la solution "crade" répondant
> au besoin.
>
> Si tu considères que c'est ici le 76 rue du Caire, tu le mets dans
> l'associatedStreet de la rue du Caire.
>
> Pour les X Cour Saint Henri, 76 Rue du Caire (ou un autre numéro pour
> l'autre entrée), tu pourrais mettre addr:flats
>  pour les numéros.
>
> Peut-être addr:place
>  pour "Saint
> Henri".
>
> Et donc pas d'associatedStreet pour ces cours car il n'y a pas
> d'associatedStreet pour les place=.
>
> addr:unit  me semble
> préférable.
>
> Du coup tu mettrais ici :
>
> addr:flats =X
> addr:unit =Cour Saint
> Henri
> addr:housenumber
> =76
>
> et le tout dans l'associatedStreet ? Osmose va râler.
>
> Alors faux positifs ou vous avez de meilleures idées ?
>
> Jean-Yvon
> Le 01/09/2020 à 17:51, Denis Chenu via Talk-fr - talk-fr@openstreetmap.org
> a écrit :
>
> Bonjour,
>
> Je suis en train de reprendre les adresses du Fantoir et de les ajouter
> sur Roubaix.
> Les adresses non encore répertorié sont souvent les courées 
> :https://fr.wikipedia.org/wiki/Cour%C3%A9e
>
> Sur le Fantoir : en général elles ont la double adresse:
> «Nom de courée Nom de la Rue»
>
> Lors de l'envoi postal, certains utilisent la double adresse
> 1 Courée nom de la Couré
> 42 rue de la rue
>
> Selon le BANO, j'ajoute ou non le nom de la rue.
> Mais je me pose la question de la double adresse ?
> Est-ce qu'il peut être intéressant d'indiquer une deuxième ligne ?
> Est sou quel format , quel tag utiliser ?
> peut être addr:full : https://wiki.openstreetmap.org/wiki/Key:addr:full ?
>
>
> Autre chose : ces courées ont des entrées qui appartiennent à la rue
> principale.
>
> Je me pose la question d'ajouter ces entrées puis de les ajouter à la
> relation ?
> Ici : une entrée que j'ai taggué 
> :https://www.openstreetmap.org/node/7864474720
>
> En image : ce que peux donner une 
> entréehttps://pic.infini.fr/L69zoN2N/kiVHull9.png (ici c'est celle ci dessus)
> ouhttps://pic.infini.fr/7iDxlOYf/KMge9ehI.png
>
> Cela est intéressant ? je continu (et ajoute les précédentes) ? Je les
> ajoute dans la relation ?
>
> Merci,
> Denis
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
>

Re: [talk-au] Admin levels for LGAs / suburbs etc changed (Was "Suburbs & admin boundaries stopping streets being found?)

2020-09-01 Thread Mike King

Hi Graeme

I’m not sure I can offer any advice on tagging but I’ve worked in land 
administration and can offer some general guidance on the hierarchy of land 
classification.  My knowledge is mostly Queensland based but I believe all of 
the states have a similar system given that ultimate authority over land is 
federal.  The nested hierarchy is simply Country>State>LGA>suburb (or 
locality)>parcel.  That is parcels comprise suburbs, suburbs comprise LGAs and 
LGAs comprise states so there is a complete coverage or fabric over the land 
and inshore areas.  The regions mentioned will most likely not have any admin 
status unless they are associated with an act of legislation (such as South 
East Queensland which now has defined boundary of the common participating 
councils).  There may be other areas such as Parishes or Counties which are 
still used in legal titles but these are largely no longer used for anything 
other than that due to the fact they were drawn up in an age which predates 
most modern systems and in a time where the local Church as something people 
recognised as a centre of an area.

Maybe someone working with cadastral fabrics in the states can provide more 
detail if required.

Kind Regards

Mike King
GIS Specialist
NHVR Solutions, Corporate Services
National Heavy Vehicle Regulator
P: 07 3309 8880 | E: mike.k...@nhvr.gov.au
PO Box 492 | Fortitude Valley QLD 4006
Gasworks | Level 3, 76 Skyring Terrace| Newstead QLD 4006
www.nhvr.gov.au
[cid:image001.gif@01D3894F.ABA64A60] 
[cid:image002.png@01D3894F.ABA64A60]    
[cid:image003.gif@01D3894F.ABA64A60] 


From: Graeme Fitzpatrick [mailto:graemefi...@gmail.com]
Sent: Wednesday, 2 September 2020 10:38 AM
To: OSM-Au
Subject: [talk-au] Admin levels for LGAs / suburbs etc changed (Was "Suburbs & 
admin boundaries stopping streets being found?)

On Mon, 31 Aug 2020 at 18:39, Andrew Harvey 
mailto:andrew.harv...@gmail.com>> wrote:
On Mon, 31 Aug 2020 at 11:21, cleary mailto:o...@97k.com>> wrote:

I looked at the Wiki. It is quite a while since I looked at the section on 
administrative boundaries. My recollection is that it used to have LGA as 
admin_level=6 and suburb as level 9 or 10.  I do not recall any discussion of 
inclusion of regions, districts and townsites nor any previous discussion in 
regard to changing the level of LGA.   The wiki includes a link to a 
downloadable example which is headed "Australian Boundary Tagging _ OSM" but 
with copyright attributed to Government of Western Australia.  I am not sure 
how the current content of wiki was arrived at.  My memory is not perfect so 
perhaps someone can remind me how the wiki content on administrative boundaries 
and the WA Government copyright document was reached.

In NSW there are land districts defined in legislation with administrative 
boards etc so they could be included if we could get permission to use the 
source data (not included in current approval as far as I am aware) and there 
are probably equivalents in other jurisdictions. I think administrative 
boundaries must be sourced from government.   In NSW,  land districts are 
larger in area than local government areas (LGAs) but their influence and 
importance is (in my view) much less than LGAs - the Greater Sydney Local Land 
Services board has the majority of its membership appointed by the Minister for 
Agriculture and few Sydney residents would even know of its existence or role.  
I'd want to put them at level 11, certainly not a higher level than the LGAs.  
I do not think that a larger area automatically warrants a higher 
administrative level.

I am open to changing and developing our guidelines. However some boundaries 
are not necessarily administrative  e.g. Eyre Peninsula (natural region),  
Barossa Valley District (protected area), Illawarra Region, New England Region. 
 Some boundaries might be tourist labels or have local currency but would need 
to be mapped as something other than administrative.

Sorry I'm getting offtopic here...

I'm only familiar with NSW but for example we have a few non-administrative 
regions/districts mapped

Illawarra https://www.openstreetmap.org/relation/7876497 tagged as place=region 
without an admin_level
Northern Beaches https://www.openstreetmap.org/relation/7876483 tagged as 
place=district without an admin_level
Lower North Shore https://www.openstreetmap.org/relation/7876484 tagged as 
place=district without an admin_level
Upper North Shore https://www.openstreetmap.org/relation/11373192 tagged as 
place=district without an admin_level
St George https://www.openstreetmap.org/relation/7876480 tagged as 
place=district without an admin_level
others could be added like The Shire, South Coast, Hunter Valley, Central 
Coast, Hills District, Eastern Suburbs, Blue Mountains + regional

[talk-au] Admin levels for LGAs / suburbs etc changed (Was "Suburbs & admin boundaries stopping streets being found?)

2020-09-01 Thread Graeme Fitzpatrick

 On Mon, 31 Aug 2020 at 18:39, Andrew Harvey 
wrote:

> On Mon, 31 Aug 2020 at 11:21, cleary  wrote:
>
>>
>> I looked at the Wiki. It is quite a while since I looked at the section
>> on administrative boundaries. My recollection is that it used to have LGA
>> as admin_level=6 and suburb as level 9 or 10.  I do not recall any
>> discussion of inclusion of regions, districts and townsites nor any
>> previous discussion in regard to changing the level of LGA.   The wiki
>> includes a link to a downloadable example which is headed "Australian
>> Boundary Tagging _ OSM" but with copyright attributed to Government of
>> Western Australia.  I am not sure how the current content of wiki was
>> arrived at.  My memory is not perfect so perhaps someone can remind me how
>> the wiki content on administrative boundaries and the WA Government
>> copyright document was reached.
>>
>> In NSW there are land districts defined in legislation with
>> administrative boards etc so they could be included if we could get
>> permission to use the source data (not included in current approval as far
>> as I am aware) and there are probably equivalents in other jurisdictions. I
>> think administrative boundaries must be sourced from government.   In NSW,
>> land districts are larger in area than local government areas (LGAs) but
>> their influence and importance is (in my view) much less than LGAs - the
>> Greater Sydney Local Land Services board has the majority of its membership
>> appointed by the Minister for Agriculture and few Sydney residents would
>> even know of its existence or role.  I'd want to put them at level 11,
>> certainly not a higher level than the LGAs.  I do not think that a larger
>> area automatically warrants a higher administrative level.
>>
>> I am open to changing and developing our guidelines. However some
>> boundaries are not necessarily administrative  e.g. Eyre Peninsula (natural
>> region),  Barossa Valley District (protected area), Illawarra Region, New
>> England Region.  Some boundaries might be tourist labels or have local
>> currency but would need to be mapped as something other than administrative.
>>
>
> Sorry I'm getting offtopic here...
>
> I'm only familiar with NSW but for example we have a few
> non-administrative regions/districts mapped
>
> Illawarra https://www.openstreetmap.org/relation/7876497 tagged as
> place=region without an admin_level
> Northern Beaches https://www.openstreetmap.org/relation/7876483 tagged as
> place=district without an admin_level
> Lower North Shore https://www.openstreetmap.org/relation/7876484 tagged
> as place=district without an admin_level
> Upper North Shore https://www.openstreetmap.org/relation/11373192 tagged
> as place=district without an admin_level
> St George https://www.openstreetmap.org/relation/7876480 tagged as
> place=district without an admin_level
> others could be added like The Shire, South Coast, Hunter Valley, Central
> Coast, Hills District, Eastern Suburbs, Blue Mountains + regional
> regions/districts.
>
> I agree that these are not administrative boundaries so I'm fine with not
> giving them an admin_level, and it's a fair argument that these are not
> verifiable on the ground, but nonetheless they do exist and people refer to
> them frequently in conversation.
>
> In terms of the admin_level for LGA's I think if we have administrative
> regions or not shouldn't really affect the admin_level value too much, I
> think going with what most other countries use for
>

Reposting this as my reply only went to Cleary, not the list, & it seems
important enough to follow up. Sorry if it's a bit messy & confused!

On Mon, 31 Aug 2020 at 11:21, cleary  wrote:

>
> I looked at the Wiki. It is quite a while since I looked at the section on
> administrative boundaries. My recollection is that it used to have LGA as
> admin_level=6 and suburb as level 9 or 10.


I had the same vague memory?

 I do not recall any discussion of inclusion of regions, districts and
> townsites nor any previous discussion in regard to changing the level of
> LGA.


Did a bit of searching & it appears it was only changed on 15/7/20, but no,
I certainly don't remember any discussion?

https://wiki.openstreetmap.org/w/index.php?title=Template:Admin_level_10=prev=2012028

Makes reference to "Australian Tagging Review (2012 / 2016)", but that
doesn't help me much either?


Thanks

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

Re: [OSM-talk-fr] maxspeed par défaut

2020-09-01 Thread Yannick

Le 02/09/2020 à 00:51, Marc Mongenet a écrit :
> Bonjour,
> 
> Près de chez moi passe la route D 903 avec une succession de portions
> à accès réglementé en 2x2 voies séparées
> (https://www.openstreetmap.org/way/825204700), à 2+1 voies
> (https://www.openstreetmap.org/way/24205655), à 1+1 voies
> (https://www.openstreetmap.org/way/6069166), à 1+1 voies séparées
> (https://www.openstreetmap.org/way/654772946), sans compter les voies
> d'insertion, etc.
> 
> De nombreuses portions ont une limite de vitesse implicite car il n'y
> a pas de panneau limitant la vitesse, et les règles générales
> s'appliquent (R413-2). Le problème est que ces règles sont mal
> connues, et presque tout a été mal mappé avec maxspeed=80. Pour
> l'instant j'ai supprimé ce qui était faux.
> 
> Mais est-ce que ça vaut la peine de mapper les limitations par défaut?
> Informatiquement parlant, ça me semble profondément contre-productif:
> c'est le boulot de l'ordinateur de calculer cela. Sauf qu'il faut tout
> de même taguer qqch pour faire la différence entre une route de
> maxspeed inconnue, et une route de maxspeed implicite. Ma question est
> donc:
> Est-ce qu'utiliser source:maxspeed=FR:rural sans maxspeed=* est une
> bonne pratique?
> 
> PS: Les règles du code de la route sont si mal connues que
> https://wiki.openstreetmap.org/wiki/FR:Key:maxspeed#Limitation_de_vitesse
> contient une erreur de 20 km/h.
> 
> Marc Mongenet

Bonsoir,

L'implicite est désormais quasi impossible à deviner. Prends les
nationales à 80 et des portions de départementales à 90. Je me mets à la
place de l'étranger pour qui c'est pire qu'un casse-tête chinois. On
finit par ne plus savoir la limite en vigueur sur telle ou telle portion
de route.
Je suis donc partisan de mettre systématiquement le maxspeed=* au moins
c'est clairement renseigné sans équivoque possible.

Amitiés


-- 
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris https://www.ancestris.org




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

Re: [talk-cz] Geofabrik chybějící data

2020-09-01 Thread Petr Vejsada

Ahoj,

Dne Út 1. září 2020 21:27:34, Jan Macura napsal(a):

> Chápu správně, že se to týká i "Aktivní vrstvy" na osmap.cz ?
> Protože ta se mi momentálně načítá jen do zoomu 12, pak už přichází z
> poloha.net jen prázdné odpovědi.

Ano, bohužel, ty odpovědi jsou z cache. JSON dlaždice se po vygenerovýání 
nakešují a zůstávají v keši nějakou dobu.

https://poloha.net/content/geofabrik-chybejici-data
**
API data nahrána, nyní běží import geometrií pro tileserver. Bohužel OSM2PGSQL 
neumožňuje v jedné transakci truncate a reimport. Dropnout tabulky také nelze, 
protože mnoho dalších objektů na nich závisí. Musel jsem je tedy vyprázdnit 
ručně což bohužel znamená, že OSM data pro tileserver teď nejsou žádná. Import 
geometrií běží od 1.9. cca 12:00 a dnes kolem poledne by snad mohl doběhnout, 
ale uvidíme. Going over pending ways and relations může zabrat dalších pár dnů.

Nahrávaný soubor:

# original OSM minutely replication sequence number 4174046
timestamp=2020-08-30T20\:42\:02Z
sequenceNumber=2717

Po importu budu aplikovat aktualizace osc.gz
**
Pro JSON dlaždice jsou třeba obě schemata, API i geometrie.

Teď mě napadl správný postup - upravit osm2pgsql a místo DROP TABLE a CREATE 
TABLE tam dát TRUNCATE TABLE, jenže už je pozdě. Autoři to neimplementovali 
https://github.com/openstreetmap/osm2pgsql/issues/758

Tak zbývá jen čekat až to doběhne.

--
Zdraví
Petr



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

[OSM-talk-fr] maxspeed par défaut

2020-09-01 Thread Marc Mongenet

Bonjour,

Près de chez moi passe la route D 903 avec une succession de portions
à accès réglementé en 2x2 voies séparées
(https://www.openstreetmap.org/way/825204700), à 2+1 voies
(https://www.openstreetmap.org/way/24205655), à 1+1 voies
(https://www.openstreetmap.org/way/6069166), à 1+1 voies séparées
(https://www.openstreetmap.org/way/654772946), sans compter les voies
d'insertion, etc.

De nombreuses portions ont une limite de vitesse implicite car il n'y
a pas de panneau limitant la vitesse, et les règles générales
s'appliquent (R413-2). Le problème est que ces règles sont mal
connues, et presque tout a été mal mappé avec maxspeed=80. Pour
l'instant j'ai supprimé ce qui était faux.

Mais est-ce que ça vaut la peine de mapper les limitations par défaut?
Informatiquement parlant, ça me semble profondément contre-productif:
c'est le boulot de l'ordinateur de calculer cela. Sauf qu'il faut tout
de même taguer qqch pour faire la différence entre une route de
maxspeed inconnue, et une route de maxspeed implicite. Ma question est
donc:
Est-ce qu'utiliser source:maxspeed=FR:rural sans maxspeed=* est une
bonne pratique?

PS: Les règles du code de la route sont si mal connues que
https://wiki.openstreetmap.org/wiki/FR:Key:maxspeed#Limitation_de_vitesse
contient une erreur de 20 km/h.

Marc Mongenet

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

Re: [talk-ph] Help fix the road network in the Philippines with MapRoulette challenges

2020-09-01 Thread Andrew Wiseman via talk-ph

Hi everyone,

I updated the MapRoulette challenges with new OSM data again, they are all 
posted here:  https://maproulette.org/browse/projects/39286 


Thanks!

Andrew 

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


> On Feb 25, 2020, at 10:38 AM, Andrew Wiseman via talk-ph 
>  wrote:
> 
> Hi everyone,
> 
> This is Andrew again from Apple. I wanted to let everyone know that we just 
> updated the MapRoulette challenges related to road network issues in the 
> Philippines with new OSM data. 
> 
> You can find all of the challenges in this MapRoulette project: 
> https://maproulette.org/browse/projects/39286 
>  and they include things like 
> overly sharp road angles, roads that cross but aren’t connected, roads that 
> aren’t connected to anything, overlapping roads, turn restrictions, roads 
> that are close but not connected to others, and other similar issues. I plan 
> to work on some of them myself too.
> 
> If you haven’t used it before, MapRoulette lets you go through potential 
> issues in OSM data one by one and either correct them or indicate they are 
> not a problem. The challenges were created with our Atlas data analysis tool: 
> https://github.com/osmlab/atlas .
> 
> If you aren’t sure what challenge to try, sharp angles or crossing roads are 
> probably the easiest but they should all be fairly straightforward.
> 
> Please let me know if you have any suggestions or feedback. Thank you! 
> 
> Andrew 
> 
> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
> ___
> talk-ph mailing list
> talk-ph@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ph

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

Re: [Talk-it] Alberi monumentali d???Italia

2020-09-01 Thread Marco Gaiarin

Mandi! Martin Koppenhoefer
  In chel di` si favelave...

> Altri casi simili?

La 'Quercia di Cimpello':

http://audit.osmz.ru/map/AM-IT#17/45.92197/12.68214

è all'incirca a un km ad Ovest di dove è realmente, la posizione reale è
all'incirca questa:

http://audit.osmz.ru/map/AM-IT#19/45.92361/12.68495


Dove è segnata attualmente, si vede con il layer 'bing', non c'è nessun
albero... 

-- 
  A noi italiani l'indignazione dura meno dell'orgasmo.
(Marco Paolini)



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

Re: [Talk-us] Trouble with getting Superior National Forest boundary to render on standard map

2020-09-01 Thread stevea

On Sep 1, 2020, at 2:46 PM, Kevin Kenny  wrote:
> 'Private' vs 'public' hits near the mark, but not in the gold.  I was trying 
> to be precise when I said that the property line determines the protected 
> status and the public access constraints. A public-access nature reserve 
> operated by an NGO (such as a private conservancy or land trust - there are 
> quite a few in my part of the world) deserves the same treatment as a 
> government-run one.

Thank you for pointing out this distinction, Kevin.  It certainly exists, such 
as in abundance in New York state where you have mapped these distinctions 
extensively.

As I was talking about the specific case of National Forests (and their odd 
"dual boundary" nature), I did not mean to exclude other (e.g. NGO) kinds of 
ownership in the greater realm of mapping.  However, in the distinct case of 
National Forests, the distinction between public and private (for "smaller, 
actually owned" polygon components vs. "larger, potentially own-able without 
additional Congressional legislation" polygon components) remains true.

So while I do not "hit the gold" in all cases, but I think the public-private 
distinction (along with the pesky "Congress has authorized further acquisitions 
out to HERE" outer-outer polygon) accurately captures what we're trying to 
better understand, better map and better render in the case of National 
Forests, I happy accept your "adjustment or correction."

Nicely, I believe we are both correct!

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

Re: [Talk-us] Trouble with getting Superior National Forest boundary to render on standard map

On Tue, Sep 1, 2020 at 3:14 PM stevea  wrote:

> Here I weigh-in with what I believe to be a crucial distinction between
> "cadastral data which are privately owned" and "data which can be
> characterized as cadastral, but which are publicly owned and are often used
> for recreation, hiking and similar human activities."
>

'Private' vs 'public' hits near the mark, but not in the gold.  I was
trying to be precise when I said that the property line determines the
protected status and the public access constraints. A public-access nature
reserve operated by an NGO (such as a private conservancy or land trust -
there are quite a few in my part of the world) deserves the same treatment
as a government-run one.

What we discuss here is the particular (peculiar?) example of national
> forests in the USA, where there are effectively "two legal boundaries, one
> actual ownership, another potential ownership."

There's a nearly parallel situation in New York, where the 'potential
ownership' in the Adirondack and Catskill Parks is, in effect, the entirety
of those parks. In that case, though, the outer boundary is indeed signed,
affects zoning to a tremendous extent, and realtors will make it quite
clear that a property is in (or is not in) the park. (It's parallel to
several national parks in the UK, and I've gotten affirmation from a number
of prominent UK mappers that these two are properly
`boundary=national_park`.)

Within these two parks, there are a great many Wild Forests and Wilderness
Areas and Intensive Use Areas and New York City Watershed Recreation Areas
and a zoo of other things that are owned by one government or another.
They, too, are mapped, since they have protection status different from the
park as a whole, and since they are the public-access portions of the park.
(They account for something like half the land area - and we're talking a
pretty huge swath; the Adirondack Park has about the same land area as the
State of Massachusetts.)  Wilderness and Intensive Use Areas tend to have
fairly compact borders (in topology, not in size!) High Peaks
https://www.openstreetmap.org/relation/6360488 and West Canada Lakes
https://www.openstreetmap.org/relation/6360511 are the largest, and as you
can see, they have few inholdings or transportation corridors.  Wild Forest
areas (a slightly less restrictive classification) are ordinarily a lot
more diffuse, with patchworks of public and private holdings. They include
messes like Saranac Lakes https://www.openstreetmap.org/relation/6362702 and
Wilcox Lake https://www.openstreetmap.org/relation/6360587
.
While the classification of any land being added to the Forest Preserve
goes through a public notice and comment period, I'm sure that someone in
the Adirondack Park Agency has on the drawing board a sketch that says,
'any conservation land that comes into our hands in *this* area will be
added to *that* wild forest', but that's not proclaimed the way it is with
National Forests.

As diffuse as they are, these are the areas that have public access, and
`protect_class=1b` (or whatever the protection class of any given area is).
The cadastre determines the land use and protection status.

We absolutely should agree (here? now?) on which of these two (or both) we
> enter into OSM.  The current situation of data in our map is scattered
> between the two and still confused in the minds of many mappers who do or
> wish to enter these data.  Since we agree they should be entered, let's
> better discuss how we enter them "properly" (by achieving consensus) and
> watch as they render according to our hammered-out-here agreements on how
> this should and will best take place.  We really are getting closer to
> doing this, thanks to excellent discussion here.

With the two great parks of New York, we've mapped both the outer bounds -
which are consistently signed, at least on the highways - and the bounds of
the state-owned conservation land - which are also signed.  With the
National Forests, it's much less clear. Ordinarily the signage does NOT
follow the proclaimed boundary - there are no National Forest signs in the
middle of Reno - but rather are posted at the first actual Forest Service
parcel that a road encounters. The markings for the individual protected
parcels are more subtle, but they're there. Generally, the proclaimed
boundary is NOT visible in the field. (By contrast, there *are*  Adirondack
Park signs on streets  in Glens Falls/Queensbury, Corinth, Broadalbin,
Mayfield,  even in the villages)

I don't mind mapping the proclaimed areas of National Forests, but it's
hard to come up with an appropriate tag since the proclamation has so
little actual effect. The actual owned areas are definitely significant and
I do *not* want to give them up. My belief is that the conservation
easements - the intermediate category - would be nothing but clutter if
rendered on a general-purpose

Re: [Talk-it] R: Edit automatici su nome strade

2020-09-01 Thread Martin Koppenhoefer

sent from a phone

> On 1. Sep 2020, at 21:49, canfe  wrote:
> 
> Supponiamo di correggere 100 Garibaldi senza Giuseppe.
> Quanti di questi, in Italia,non saran Giuseppe??
> TRE?? Penso anche meno.

io anche lo vedo pragmatico: prima c’erano (supponiamo) 300 Giuseppe Garibaldi 
lunghi e 100 corti. Dai corti si sapeva che la maggior parte erano 
probabilmente Giuseppi, e soprattutto si sapeva di non sapere bene, e non 
c’erano errori (supponiamo).
Dopo ci sono molto probabilmente errori (pochi) e ci sono 400 Giuseppe 
Garibaldi.

Un nome incompleto può sempre suscitare interesse di indagare, mentre un nome 
completo sbagliato ci rimane potenzialmente per parecchio tempo.

Non si guadagna un granché ma si paga con errori “statisticamente certi”, non 
lo farei.

Ciao Martin 

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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

De façon pragmatique on peut admettre d'avoir simplement les deux (un noeud
et une surface), sans aucune relation, et faire en sorte que cela ne
s'affiche pas deux fois (un point parking trouvé dans une surface parking
peut être éliminé, peu importe si tous les autres tags dont le nom ne sont
pas identiques, on n'affichera qu'un seul nom (peut importe lequel même si
ça diverge un peu), en fusionnant "intelligemment" les tags trouvés (si
nécessaire on peut faire un log d'erreurs pour signaler les valeurs en
conflit même si on n'en retient qu'une arbirtrairement sur le rendu).

En revanche il peut être utile de conserver certains tags spécifiques (pas
tous) comme la délimitation des places réservées aux handicapés, ou les
parkings 2 roues sans avoir besoin d'afficher leur nom en doublon visible.

Dans tous les cas, pas besoin de label ni de relation.

Attention dans certains cas il y a des places réservées de façon
privées dans les parkings public (exemples: places réservées au personnel
porteurs d'une carte spécial, ou places protégées par une barrière ou un
plot levant (à clé ou télécommandé).En principe on devrait délimiter ces
places avec une autre surface séparée indiquant leur caractère privé. mais
si cela ne concerne qu'un ou deux emplacements, il y a un tag particulier
pour ces emplacements individuels placés dans un parking plus grand.

De même pour les aires de stationnement pour camions, bus et véhicules
longs ou à remorque (qui ne leur sont pas forcément réservés mais ces
véhicules ne peuvent pas se garer dans les plus petits emplacements). Ce
cas se présente notamment sur les aires d'autoroutes. Il peut arriver que
les emplacements pour véhicules de tourisme soient pleins et qu'il aillent
s'aligner plus loin sur les aires pour véhicule longs, mais en principe on
devrait éviter de laisser libre les emplacements longs partiellement
occupés, afin de laisser de la place pour les autres véhicules longs (comme
ces places sont souvent plus éloignées des points de service, naturellement
les véhicules remplissent d'abord les emplacements les plus proches et se
regroupent). Cela pose rarement des problèmes. Si c'est un stationnement
pour le repos, il y a des emplacements mieux adaptés que ces grandes places
souvent trop lumineuses et sans craindre de se faire déranger par des
camions ou des cars...



Le mar. 1 sept. 2020 à 09:58, Christian Quest  a
écrit :

> Le 30/08/2020 à 21:20, osm.sanspourr...@spamgourmet.com a écrit :
>
> Le 30/08/2020 à 09:46, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Bien souvent dans mes contributions, je remet des POI en surfacique alors
> qu'ils ne sont que ponctuels, la première étape consistant souvent à migrer
> un tag sur un bâtiment entier, mais la seconde, quand on le peut, consiste
> à délimiter plus largement l'emprise de tel ou tel POI. Cas typique: les
> écoles !
>
> J'allais dire ouille.
>
> Car les *points* d'intérêt  ne sont pas des *surfaces* par définition.
>
> Tout dépend de la définition... point d'intérêt ou ponctuel d'intérêt ;)
>
> Attention aussi à la traduction simpliste qu'on a fait de POI, non ?
>
> Réduire un POI à un unique point est quand même une façon minimaliste de
> décrire un lieu rarement ponctuel sur le terrain. J'ai toujours considéré
> qu'un ponctuel c'était bien pour apporter une info minimale, mais qu'une
> surface apporte bien plus d'infos (où commence le POI, où s'arrête-t-il,
> est-il étendu ou pas, etc).
>
>
> Si par contre tu parles d'objets de nature surfacique telles qu'un parking
> ou un jardin, on est d'accord.
>
> Pour une école je ne sais : tu mets ça sur le landuse ?
>
> Oui, plutôt, quand on peut déterminer l'emprise sinon où mettre le
> ponctuel à part de façon arbitraire ?
>
>
> Ceci dit souvent quand le PI est surfacique des cartographes (avec
> StreetComplete et autres GoMap) l'ajoutent en ponctuel car leur appli ne
> montre que les PI ponctuels :-(.
>
> Faire un rendu ponctuel peut se comprendre, un parking aura un "P" vers le
> centroid, éventuellement son emprise aura un style surfacique en plus. Le
> nom doit être placé quelque part, il est donc ponctuel lui aussi mais
> déterminé à partir de l'emprise.
>
>
> La seule solution propre compatible avec les deux mais lourdingue pour les
> petits objets c'est de faire une relation type=boundary avec le nœud comme
> label et le contour en outer comme ici
> .
>
> Bof bof bof... que de complexité pour un usage quasi nul des rôles label,
> d'autant plus que remonter dans les relations est un exercice délicat pour
> les moteurs de rendu.
>
> Dans ce cas précis, je ne trouve pas que la position pour ce label soit
> bien choisie. Elle est trop proche de la route, donc collision avec le nom
> de celle-ci (identique d'ailleurs).
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
>

Re: [Talk-us] Opinions on Devil's Slide Bunker (San Mateo, CA)

2020-09-01 Thread Bill Ricker

On Tue, Sep 1, 2020 at 3:42 PM Russell Nelson  wrote:

> On 9/1/20 3:08 PM, Bill Ricker wrote:
> > Tourist Safety is dubiously best as most of the handrails and safety
> > lines are gone
> s/dubiously best/dubious at best/ ?
>

Russ is correct on the missing word !
Might be Auto-Carrot, i was typing on glass ...
-- 
Bill Ricker
bill.n1...@gmail.com
https://www.linkedin.com/in/n1vux
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] No U-turn vs BRouter

Le mar. 1 sept. 2020 à 14:04,  a écrit :

> TL;DR: overtaking=no
> Le 01/09/2020 à 12:35, Francois Gouget - fgou...@free.fr a écrit :
>
> On Sun, 30 Aug 2020, Francois Gouget wrote:
> [...]
>
> Je pense que le no-u-turn était sensé indiquer qu'on ne doit pas faire
> demi-tour là où les deux voies se rejoignent. Cela me parait très
> superflu.
>
> En fait les restrictions ne sont pas totalement superflues 
> :https://brouter.de/brouter-web/#map=19/45.78552/-1.15725/standard=-1.156756,45.785759;-1.158315,45.785505=car-eco
>
> Si superflues car fausses (mauvais tag).
>

Je dis faux car mauvaise interprétation ! En France à moisn de 50 mètres du
rond-point c'est interdit (ça devrait être signalé par un panneau mais là
on n'indique pas dans OSM la position de ces panneaux d'approche d'un
rond-point.

Il suffirait déjà de mettre une limtie de 50 mètres par défaut pour
éliminer ces très mauvais conseils de parcours. Le routeur pourrait estimer
aussi la largeur de la chaussée, l'absence de zone latérale de dégagement
(stationnement le long de la voie, absence de voie cyclable, présence sur
la voie publique de bateaux d'entrées de voies privées ou de garage, où
l'arrêt est possible et même marqué au sol pour interdire non pas l'arrêt
mais le stationnement)

et l'angle du tracé doit servir à déterminer et un rayon de courbure
minimal doirt permetre d'estimer correctement la place nécesaire pour voir
si c'st possible de faire une maeuvre unique sans sortir de la voie
publique ou empiéter trottoirs ou voies cyclables et sans marche arrière.
Un autre indicateur est celui du nombre de voies (2 par défaut sur les
rues/routes bidirectionnelles, à moins qu'on ait mis autre chose, soit
seulement 3,5 mètre de largeur en moyenne par voie: pour faire un demi-tour
complet sans marche arrière, on est plus proche des 10 mètres avec une
voiture, il faut au moins 3 voies ou un dégagement latéral pour le faire
sans s'arrêter en bloquant  les deux voies et à moins de 50 mètres du
rond-point c'est trop dangereux.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] No U-turn vs BRouter

Le mar. 1 sept. 2020 à 12:36, Francois Gouget  a écrit :

> * Je ne me vois pas faire demi-tour (en fait tourner à gauche) comme ça
>   en sortie de rond-point. Mais s'il y a une ligne discontinue cela
>   serait-il vraiment interdit ?
>

En pratique oui, pour la police ou pour les assurances, si ils estiment que
la manœuvre était trop dangereuse (manque de visibilité, aux distances de
freinage bien connues et selon les limites de vitesse applicables).

Le code de la route précise bien que la signalisation, même si elle *peut*
être impérative (pour le cas courant) n'exclue pas le jugement et le
bon-sens du conducteur, et le respect des autres usagers (même quand ils
commettent des interdits, notamment les piétons et cyclistes qui eux n'ont
aucune assurance spécifique obligatoire pour couvrir les frais des
accidents et le //pretium doloris// ou les autres conséquences comme les
incapacités, arrêts de travail, pertes d'emploi ou inadéquations aux postes
pour lesquels ils sont formés et frais de réadaptation/rééducation).

Un conducteur disposant d'une assurance obligatoire est toujours
responsable devant quiconque n'a pas d'obligation à en avoir (cette
responsabilité sera prise en charge par son assurance mais des malus
peuvent cependant s'appliquer suite à cette prise en charge ou une
radiation ultérieure du contrat qui cependant reste applicable à ce dommage
couvert), et s'il n'est pas valablement assuré il commet un délit pénal qui
sera sanctionné en plus des réparations qu'on lui réclamera (et pas la
peine de chercher chez sont assureur, il fera tout pour nier toute
couverture s'il y a un délit quelconque, et c'est marqué dans ses contrats,
au mioeux il n'applisera qu'une responsabilité partagée pour son calcul de
malus à condition de faire appel de sa décision, ce qui nécessite souvent
de le poursuivre en justice et prendra du temps; pire, si on a plusieurs
assurances, elles se renverront entre elles la prise en charge du même
dommage et là aussi on doit aller en justice pour faire désigner un
assureur qui prendra en charge le dossier et négociera lui-même avec les
autres ou fera fonctionner ses systèmes de réasurances et demandera aussi à
être partie civile pour récupérer une partie des versements par la sécu ou
autres compensations publiques, y compris sur les indemnités journalières
ou de chomage; souvent c'est donnat-donnant, le principe étant juste de
couvrir l'urgent mais pas l'avenir, là encore il faut souvent aller en
justice si on estime que l'assureur nous doit plus et que ses demandes
étaient disproprotionnées ou mal évaluées).

Tout conducteur est normalement sensibilisé pendant sa formation sur la
conduite "avec prudence" qui est une obligation (guidée en partie mais pas
seulement par la réglementation obligatoire). Il doit rester maître de son
véhicule et connaitre ses capacités, apprendre à faire ses
manœuvres rapidement pour ne pas gêner ou créer de danger supplémentaire
pour les autres et il doit être prompt à réagir ou à signaler tout problème
technique. Faire un demi-tour en sortie de rond-point sur un espace exigu
ne permet souvent pas de le faire en sécurité (pour soi ou les autres) en
un temps court avant qu'un danger arrive (notamment des autres véhicules
sortant du rond-point qui ne sont pas sensés devoir stopper brutalement
même s'ils respectent les vitesses limités (cependant ceux qui sortent d'un
rond point doivent s'attendre à trouver un passage piétons protégé sur le Y
et leur laisser le passage, et s'il le faut en s'arrêtant sur l'anneau.
Mais s'ils ne voient aucun piéton, juste un véhicule devant eux, il peuvent
reprendre un peu de vitesse et ne s'attendent pas à voir ce véhicule piler
pour faire demi-tour en plusieurs manœuvres coupant les deux sens dont
souvent une marche arrière en contre-sens de la voie de sortie.

La ligne continue n'est pas une obligation des collectivités sur le
terrain, même si elles est prescriptive, c'est avant tout un rappel: à
moins de 50 mètres d'un rond-point (distance minimale de signalisation
utile selon la loi), il y a une interdiction de fait car le rond-point
lui-même était signalé avant d'y entrer, lui aussi à 50 mètres au moins: si
on n'a pas encore passé après avoir franchi le rond-point le panneau
alertant d'un rond-point à 50 mètres dans l'autre sens, on doit faire comme
si c'était une ligne continue (même si on ne voit pas la face de ce panneau
destinée à l'autre sens, il s'appliquera de toute façon après le demi-tour,
et il n'est pas prudent de faire demi-tour quand il y un panneau dans
l'autre sens qu'on n'a même pas encore vu et qui pourtant indique une zone
de danger pleinement signalée et applicable.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les courée de Roubaix : adresse et entrée


J'aurais tendance à voir ça comme une rue à part.

Mais pour la double adresse, addr:full est la solution "crade" répondant
au besoin.

Si tu considères que c'est ici le 76 rue du Caire, tu le mets dans
l'associatedStreet de la rue du Caire.

Pour les X Cour Saint Henri, 76 Rue du Caire (ou un autre numéro pour
l'autre entrée), tu pourrais mettre addr:flats
 pour les numéros.

Peut-être addr:place
 pour "Saint Henri".

Et donc pas d'associatedStreet pour ces cours car il n'y a pas
d'associatedStreet pour les place=.

addr:unit  me semble
préférable.

Du coup tu mettrais ici :

addr:flats =X
addr:unit =Cour Saint
Henri
addr:housenumber
=76

et le tout dans l'associatedStreet ? Osmose va râler.

Alors faux positifs ou vous avez de meilleures idées ?

Jean-Yvon

Le 01/09/2020 à 17:51, Denis Chenu via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Bonjour,

Je suis en train de reprendre les adresses du Fantoir et de les ajouter
sur Roubaix.
Les adresses non encore répertorié sont souvent les courées :
https://fr.wikipedia.org/wiki/Cour%C3%A9e

Sur le Fantoir : en général elles ont la double adresse:
«Nom de courée Nom de la Rue»

Lors de l'envoi postal, certains utilisent la double adresse
1 Courée nom de la Couré
42 rue de la rue

Selon le BANO, j'ajoute ou non le nom de la rue.
Mais je me pose la question de la double adresse ?
Est-ce qu'il peut être intéressant d'indiquer une deuxième ligne ?
Est sou quel format , quel tag utiliser ?
peut être addr:full : https://wiki.openstreetmap.org/wiki/Key:addr:full ?


Autre chose : ces courées ont des entrées qui appartiennent à la rue
principale.

Je me pose la question d'ajouter ces entrées puis de les ajouter à la
relation ?
Ici : une entrée que j'ai taggué :
https://www.openstreetmap.org/node/7864474720

En image : ce que peux donner une entrée
https://pic.infini.fr/L69zoN2N/kiVHull9.png (ici c'est celle ci dessus)
ou
https://pic.infini.fr/7iDxlOYf/KMge9ehI.png

Cela est intéressant ? je continu (et ajoute les précédentes) ? Je les
ajoute dans la relation ?

Merci,
Denis



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

[Talk-GB] OSM UK meeting

2020-09-01 Thread Rob Nickerson

Hi all,

The notification of the next OSM UK general meeting has now been sent out
to all paid up members. We decided that it was best to do this as an online
event giving the ongoing situation. We've picked Saturday 17th October at
1pm.

The general meeting itself should be a relatively short affair. It includes
election of new Directors, agreement on future membership fees and a look
over the accounts. We think this will take no more than 45 minutes. Beyond
that, we don't have anything else that we need to do but are open to the
idea of extending the event if there are things that others would like to
include.

Please let us know if there are topics you would like adding to the day.
Also if you have suggestions for speakers we can certainly reach out to
them but no guarantees. The best plan is one which we can do without having
to find others input.

Thank you,
*Rob*
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [talk-cz] Import zastávek veřejné dopravy Jihočeského kraje

2020-09-01 Thread Majkaz

1. 9. 2020 18:22:45 <0174 :

> Ahoj,
> já bych dal celý název do name. Na zastávkách je celý název obvykle psaný 
> (nevím jak je to se standardizací v Jihočeském kraji), příklad z JMK:
> https://upload.wikimedia.org/wikipedia/commons/a/ab/Moravsk%C3%BD_Krumlov%2C_U_N%C3%A1dra%C5%BE%C3%AD%2C_autobusov%C3%A1_zast%C3%A1vka.jpg
> A "on the ground" princip zrovna tohle udává jako příklad:
> 
> "Sometimes there's conflicting information about, say, the name of a place. 
> [...People...] need to find the names from local signs in the map [...]"
> 
>> V name alespoň v Budějovicích už hodnoty jsou. Jsou to léta používané názvy 
>> zastávek, tak se i hlásí. Jen není možné je ani tady jednoznačně získat z 
>> oficiální podoby jízdních řádů.
Proto jsem chtěla použít tu značku ref_name, kterou uvádí anglická wiki přesně 
k tomuhle účelu.
Konkrétně: 80% zastávek bude používat jen třetí část toho dlouhého názvu (v 
dlouhém názvu jsou České Budějovice),  zbytek použije 1. a 3. část oddělenou 
čárkou (samostatné obce v okolí, obsluhované MHD). Za minimálně posledních 30 
let se ty názvy používají takhle. Na dálku ale z toho souboru nikdo nepozná,  
že zastávky toho druhého typu jsou zastávky MHD v ČB. Navíc třeba "Dobrá Voda u 
Č.Budějovic,,Domov důchodců" se používá a v datech je jako "Dobrá Voda, Domov 
důchodců".

Tím se dostáváme k jádru problému: Pokud to přepíšu v name, na jedné straně 
přemažu  stávající hodnoty něčím, co se tak ve skutečnosti nikde mimo 
internetových jízdních řádů nepoužívá. K tomu do jména nacpu spoustu hodnot 
obsahujících ",,". To si říká o to, aby to někdo hned poté "opravil". V 
ref_name doufám, že to vydrží bez vylepšení.
A poslední problém: U část hodnot se krátký název zkrátka zjistí jen na místě, 
nebo na schématech dopravního podniku  - speciálně u MHD, viz výše.

Majka

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

Re: [Talk-it] R: Edit automatici su nome strade

2020-09-01 Thread Marco Minghini

Ciao,

Hai formalmente ragione Andrea, però… la vedo pragmaticamente.
> Supponiamo di correggere 100 Garibaldi senza Giuseppe.
> Quanti di questi, *in Italia*,non saran Giuseppe??
> TRE?? Penso anche meno.
> Allora avremo fatto 97 cose valide a scapito di tre sbagliate.
>

Corretto, ma il metodo con cui si mappa in OSM non prevede il tirare a
caso, quindi non si può fare :)

Se ricordate, l'utente mcheck qualche mese fa aveva fatto modifiche massive
nel nord Italia a seguito di note anonime che chiedevano di correggere nomi
di strade in base alle regole ISTAT - il problema era che i suggerimenti di
correzione delle note non erano del tutto corretti e in linea con ISTAT.
Quindi mcheck aveva fatto modifiche massive errate e io e Lorenzo Stucchi
(più lui che io in realtà) avevamo aggiustato le cose a manina In quel
caso l'utente aveva risposto a qualche changeset, ma ormai era tardi. Ma mi
sembra che segua la mailing list, quindi spero risponda lui direttamente
qui.

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

[Talk-it] R: Edit automatici su nome strade

2020-09-01 Thread canfe

Hai formalmente ragione Andrea, però… la vedo pragmaticamente.
Supponiamo di correggere 100 Garibaldi senza Giuseppe.
Quanti di questi, in Italia,non saran Giuseppe??
TRE?? Penso anche meno.
Allora avremo fatto 97 cose valide a scapito di tre sbagliate.

 

Se i miei investimenti in borsa avessero successo il 97% delle volte, penso 
potrei offrire a tutta la comunità OSM europea dei server da favola.

 

Ferruccio Cantone (canfe)

 

Da: Andrea Musuruane [mailto:musur...@gmail.com] 
Inviato: martedì 1 settembre 2020 10:16
A: openstreetmap list - italiano
Oggetto: [Talk-it] Edit automatici su nome strade

 

Ciao,

vorrei sottoporre alla vostra attenzione che l'utente mcheck sta 
modificando massivamente gli odonimi:

https://www.openstreetmap.org/user/mcheck/history

 

Ho commentato un paio di changeset.

 

Questi mass edit, oltre a non essere concordati e non seguire le guidelines, 
non hanno senso perché senza conoscenza del luogo non si può sapere se la 
strada fosse intitolata a qualcun altro con lo stesso cognome.

 

Per esempio:

https://it.wikipedia.org/wiki/Garibaldi_(disambigua)#Persone

https://it.wikipedia.org/wiki/Mazzini_(disambigua)#Persone

 

Ciao,

 

Andrea

 

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

Re: [Talk-us] Opinions on Devil's Slide Bunker (San Mateo, CA)

2020-09-01 Thread Russell Nelson


On 9/1/20 3:08 PM, Bill Ricker wrote:
Tourist Safety is dubiously best as most of the handrails and safety 
lines are gone

s/dubiously best/dubious at best/ ?

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

Re: [OSM-talk-fr] No U-turn vs BRouter

2020-09-01 Thread Frédéric Rodrigo


Le 01/09/2020 à 14:03, osm.sanspourr...@spamgourmet.com a écrit :

* Je ne me vois pas faire demi-tour (en fait tourner à gauche) comme ça
   en sortie de rond-point. Mais s'il y a une ligne discontinue cela
   serait-il vraiment interdit ?


Non, si la ligne est discontinue tu as le droit (enfin là tu es sur 
une départementale).


Mais tu ne dois pas le faire (en cas d'accident tu auras tort) car du 
fait du giratoire, tu ne peux voir assez les véhicules venant de 
l'arrière.


Sur Paris c'est interdit 
 
sauf à un carrefour (mais OSM ne connaît cette règle).


Ça dépend aussi du pays. Je voulez gérer ça dans Osmose. Mais je n'ai 
jamais trouver de liste de ce détails du code de la route par pays.




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

Re: [OSM-talk-fr] Rond point et relations routes

> Pour les relations de transports, les arrêts dans le bon ordre ça suffit 
> (plan schématique) !
> 
Pour un gestionnaire de réseau, savoir exactement ou passe le bus est utile en 
cas de travaux, bouchons… ne serait-ce que pour estimer les retards ou 
simplement calculer les temps de trajet.

Pour un cycliste ou un randonneur (à pied, à cheval…) avoir le trajet exacte 
est précieux.
En théorie, l'itinéraire est balisé sur le terrain… en pratique ?
Pour la rando, il y a les dénivelés à prendre en compte pour adapter 
éventuellement son parcours.
Et quand il y a des conflits avec les propriétaires, c'est aussi important de 
passer au bon endroit :D
> Pour les réseaux de bus, oui Yves si on veut un parcours réaliste, c'est 
> bien, façon "plan du réseau",
> 
> sauf que pour le rendu il faudra lancer les calculs d'itinéraires (pour au 
> final stocker les différents chemins).
> 
Oui, au final la machine va effectivement gérer les morceaux de segments (les 
calculs peuvent-être réalisé qu'une seule fois).

Mais pour la personne qui maintient les relations ça change la donne : la 
découpe de chemins ne change rien…
On évitera de perdre bêtement du temps à réparer sans cesse les mêmes relations.
> Yves : et pour afficher le trajet de manière lisible sur osm.org, tu demandes 
> à Tom ? ;-)
> 
Je vais demander à Sarah, c'est elle qui a écrit Waymarked Trails :)

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

Re: [talk-cz] Geofabrik chybějící data

2020-09-01 Thread Jan Macura

Ahoj

On Tue, 1 Sep 2020 at 01:04, Petr Vejsada  wrote:

> No nic, 2 týdny uplynuly a ty změnové soubory už asi nebudou. Začal jsem s
> reimportem.
>
> Resumé - Geofabrik ztratila obsah 2 změnových souborů a už ho asi
> neobnoví. Import nějakou dobu poběží, asi řádově dny. Počítám že do konce
> týdne by mělo být všechno zase OK. Ono to vykreslení map také chvíli trvá.
>

Chápu správně, že se to týká i "Aktivní vrstvy" na osmap.cz ?
Protože ta se mi momentálně načítá jen do zoomu 12, pak už přichází z
poloha.net jen prázdné odpovědi.

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

Re: [Talk-us] Trouble with getting Superior National Forest boundary to render on standard map

2020-09-01 Thread stevea

Here I weigh-in with what I believe to be a crucial distinction between 
"cadastral data which are privately owned" and "data which can be characterized 
as cadastral, but which are publicly owned and are often used for recreation, 
hiking and similar human activities."

Joseph, many others in OSM, I and wide consensus agree that the former (private 
cadastral data, especially down to the level of individual parcels) generally 
do not belong in OSM.  I believe we also agree there are widely-acknowledged 
exceptions to this, such as when polygons tagged landuse=* denote where a farm 
is distinct from a forested area, or where residential vs. commercial vs. 
industrial areas clearly follow property lines up to an edge of "difference," 
especially as they better characterize what we might call "zoning" (of larger 
areas like "neighborhoods" or "downtown's shopping district" or "the industrial 
zone where auto parts are manufactured by numerous industrial companies on 
numerous parcels") instead of individual parcels.  If I am incorrect in any of 
my assumptions, I welcome adjustment or correction.

However, with PUBLIC "cadastral data" which define national parks, large areas 
used for human recreation (such as state parks, county parks, national forests 
and similar public lands), I don't think there is any argument whatsoever that 
OSM wishes to map these.  Yet what Joseph characterizes as "cadastral data" 
precisely define these.  Please, let's dispense with this apparent (but not 
actual) contradiction:  public lands belong in OSM denoted as such, and an 
acknowledged best method to do this is to map their boundary as the data where 
they are "owned by the public."

What we discuss here is the particular (peculiar?) example of national forests 
in the USA, where there are effectively "two legal boundaries, one actual 
ownership, another potential ownership."  We absolutely should agree (here? 
now?) on which of these two (or both) we enter into OSM.  The current situation 
of data in our map is scattered between the two and still confused in the minds 
of many mappers who do or wish to enter these data.  Since we agree they should 
be entered, let's better discuss how we enter them "properly" (by achieving 
consensus) and watch as they render according to our hammered-out-here 
agreements on how this should and will best take place.  We really are getting 
closer to doing this, thanks to excellent discussion here.

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

Re: [Talk-us] Opinions on Devil's Slide Bunker (San Mateo, CA)

2020-09-01 Thread Bill Ricker

On Sun, Aug 30, 2020, 19:55 stevea  wrote:

> .  And if it was historically a bunker, OSM should strive to tag this, I'm
> not exactly sure of the right mix of military=bunker and historic=yes
> flavors that might be absolutely correct, but something like those if not
> exactly those.  Though historic=ruins seems correct, too, so perhaps better
> than "yes."
>

Technically this and most of what the public refers to as military bunkers
aren't bunkers.

 Many of the larger ones are casemated Coast Artillery gun positions and
their magazines. These are protected to a degree better than a "bunker"
from above, but had openings to seaward to fire which had only
splinter-proof shielding, and these were not refuges for personel, so not
true 'bunkers', they were fighting positions.

Devil's Slide was a protected Fire Control post for Coast Artillery, and
included a radar. (One could almost classify the radar control point as a
bunker, as it had no windows nor fire ports, but again it's not a refuge.)

http://www.fortwiki.com/Devil%27s_Slide_Military_Reservation

I am a member of the Coast Defense Study Group (cdsg.org) as well as OSM.
We study and seek to preserve these structures and the memories of those
who built and served in them. One of our members was recently authorized to
inspect Devil's Slide Reservation and reported on its current condition
(and history) in an illustrated article in our Coast Defense Studies
Journal. In addition to no-access signage it is gated and fenced. Tourist
Safety is dubiously best as most of the handrails and safety lines are gone
or deficient.

(The nice thing about touring these sites with CDSG conferences - aside
from knowledgeable companions - is that we negotiate "Authorized Persons
Only" access, for which we sign copious liability waivers, and we equip and
conduct ourselves appropriately for the expected hazards: hard hats or
better, construction boots (or sometimes wellies/waders!), gloves,
torches/flashlights, etc.)

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

Re: [OSM-talk-fr] Rond point et relations routes


Bonjour, oui, il y a plusieurs niveaux qui se mêlent :

- le niveau surfacique. Là on n'en parle pas mais avec les chemins
piétons et éventuellement pistes cyclables dessinés à côté on s'en approche.

Avec la découpe des entrées-sorties au niveau des séparateurs de
chaussée triangulaires aussi.

- le niveau logique.

Là on va de telle route à telle route en passant par tel giratoire.

Représenter le giratoire comme un point suffit  :

Inutile d'avoir la découpe de la route en multiples sections.

Pour les relations de transports, les arrêts dans le bon ordre ça suffit
(plan schématique) !

Pour les réseaux de transport, ça va dépendre : coté métro on va
seulement grossièrement suivre les directions (à 45 °C près) et les
distances.

Pour les réseaux de bus, oui Yves si on veut un parcours réaliste, c'est
bien, façon "plan du réseau", sauf que pour le rendu il faudra lancer
les calculs d'itinéraires (pour au final stocker les différents chemins).

Mais à mon avis ce qui pêche un peu c'est le mélange d'infos de
précision variable : on n'a pas besoin dans un plan de bus de savoir
s'il va éviter le séparateur de chaussée par la gauche ou par la droite,
on espère sauf cas spécial

que ce sera par la droite.

Francois, pour le calcul d'itinéraire j'ai voulu tester un rond point
pour lequel manque réellement une patte de chemin piéton, aucun moteur
n'a réussi sauf BRouter en mode piéton
.

Yves : et pour afficher le trajet de manière lisible sur osm.org, tu
demandes à Tom ? ;-)

Jean-Yvon

Le 01/09/2020 à 19:44, Yves P. - yves.prat...@gmail.com a écrit :

C'est vite ingérable et pourtant j'ai tout le réseau en tête.

Oui.


Malheureusement je ne vois aucune solutions pour éviter cela.


Je propose de faire une relation route basée sur des noeuds : Exemple

Pour faire ce pseudo trajet de bus, il me faut décrire que 3 noeuds
(sans rien découper).

Avec les relations actuelles, je dois découper 3 chemins. Une des rues
à parcourir est composée de 2 segments.
Ça fait donc au final 5 way à décrire.

Ici j'utilise des nœuds qui font partie des chemins.

L'idéal serait d'utiliser des noeuds quelconques (que le nœud soit sur
le chemin ou pas) :

  * les arrêt de bus
  * les panneaux indicateurs de randonnées


A tester.

Donc une relation serait composée uniquement de noeuds, avec des rôles
comme arrêt ou point d'intersection.
Dans l'exemple, ,un a 2 "arrêts" (départ et arrivée) et une intersection.

Actuellement on a ça, avec les chemins en plus et les "intersections"
en moins.
Mais JOSM a du mal à trier le tout : il met tous les arrêts et
panneaux ensemble (dans quel ordre ???), puis tous les chemins qu'il
ordonne bien à condition que le trajet soit linéaire.

__
Yves

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

Re: [Talk-it] Edit automatici su nome strade

2020-09-01 Thread Manuel


Vedo che ha ricevuto già due blocchi e l'ultimo perché era poco propenso a 
rispondere ai commenti fatti ai suoi changeset. Vedo anche che l'ultima volta 
che ha risposto a un commento su un changeset era dicembre scorso e da allora 
ha ricevuto diversi commenti ai quali non ha mai risposto. Speriamo stavolta 
sia più loquace.

Manuel
Il 01/09/2020 20:24, Cascafico Giovanni ha scritto:

Ho commentato un changeset Garibaldi. Difficile non sia Giuseppe, ma il metodo 
è fallibile.

Il mar 1 set 2020, 10:15 Andrea Musuruane mailto:musur...@gmail.com>> ha scritto:

Ciao,
    vorrei sottoporre alla vostra attenzione che l'utente mcheck sta 
modificando massivamente gli odonimi:
https://www.openstreetmap.org/user/mcheck/history

Ho commentato un paio di changeset.

Questi mass edit, oltre a non essere concordati e non seguire le 
guidelines, non hanno senso perché senza conoscenza del luogo non si può sapere 
se la strada fosse intitolata a qualcun altro con lo stesso cognome.

Per esempio:
https://it.wikipedia.org/wiki/Garibaldi_(disambigua)#Persone
https://it.wikipedia.org/wiki/Mazzini_(disambigua)#Persone

Ciao,

Andrea

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

Re: [Talk-it] Edit automatici su nome strade

2020-09-01 Thread Cascafico Giovanni

Ho commentato un changeset Garibaldi. Difficile non sia Giuseppe, ma il
metodo è fallibile.

Il mar 1 set 2020, 10:15 Andrea Musuruane  ha scritto:

> Ciao,
> vorrei sottoporre alla vostra attenzione che l'utente mcheck sta
> modificando massivamente gli odonimi:
> https://www.openstreetmap.org/user/mcheck/history
>
> Ho commentato un paio di changeset.
>
> Questi mass edit, oltre a non essere concordati e non seguire le
> guidelines, non hanno senso perché senza conoscenza del luogo non si può
> sapere se la strada fosse intitolata a qualcun altro con lo stesso cognome.
>
> Per esempio:
> https://it.wikipedia.org/wiki/Garibaldi_(disambigua)#Persone
> https://it.wikipedia.org/wiki/Mazzini_(disambigua)#Persone
>
> Ciao,
>
> Andrea
>
> ___
> 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] Errori da principianti

2020-09-01 Thread emmexx

Ecco cosa può succedere quando un principainte sbaglia a mappare:

https://www.theverge.com/2020/8/21/21395084/microsoft-flight-simulator-melbourne-obelish-openstreetmap-bing-maps-data-glitch

;-)

maxx

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

Re: [OSM-talk-fr] Rond point et relations routes

> C'est vite ingérable et pourtant j'ai tout le réseau en tête.
Oui.

> Malheureusement je ne vois aucune solutions pour éviter cela.

Je propose de faire une relation route basée sur des noeuds : Exemple 

Pour faire ce pseudo trajet de bus, il me faut décrire que 3 noeuds (sans rien 
découper).

Avec les relations actuelles, je dois découper 3 chemins. Une des rues à 
parcourir est composée de 2 segments.
Ça fait donc au final 5 way à décrire.

Ici j'utilise des nœuds qui font partie des chemins.

L'idéal serait d'utiliser des noeuds quelconques (que le nœud soit sur le 
chemin ou pas) :
les arrêt de bus
les panneaux indicateurs de randonnées

A tester.

Donc une relation serait composée uniquement de noeuds, avec des rôles comme 
arrêt ou point d'intersection.
Dans l'exemple, ,un a 2 "arrêts" (départ et arrivée) et une intersection.

Actuellement on a ça, avec les chemins en plus et les "intersections" en moins.
Mais JOSM a du mal à trier le tout : il met tous les arrêts et panneaux 
ensemble (dans quel ordre ???), puis tous les chemins qu'il ordonne bien à 
condition que le trajet soit linéaire.

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

Re: [OSM-talk-fr] No U-turn vs BRouter

2020-09-01 Thread Francois Gouget

On Tue, 1 Sep 2020, osm.sanspourr...@spamgourmet.com wrote:
[...]
> > En fait les restrictions ne sont pas totalement superflues :
> > https://brouter.de/brouter-web/#map=19/45.78552/-1.15725/standard=-1.156756,45.785759;-1.158315,45.785505=car-eco
> Si superflues car fausses (mauvais tag).

C'est plus relation incomplète dans ce cas précis : il manque le to.

L'exemple était peut-être mal choisi mais on observe le même problème 
sur les rond-points sans restriction.

> Sur Paris c'est interdit
> 
> sauf à un carrefour (mais OSM ne connaît cette règle).

HS : C'est pratique ces petites lois locales qui ne sont indiquées nul
 part sur la route ! Nul n'est sensé ignorer la loi mais quand elle 
 est publiée dans le classeur fermé à clef d'un sous-sol sans 
 éclairage...

-- 
Francois Gouget   http://fgouget.free.fr/
  E-Voting: Those who cast the votes decide nothing.
 Those who count the votes decide everything.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Alberi monumentali d’Italia

2020-09-01 Thread Volker Schmidt

Devo ancora trovare quest'albero
:-(
Suppongo che sia dentro quel parco, che si chiama appositamente Parco dei
Faggi.
La mia domanda era essenzialmente: se non lo vedo primo colpo, in che
raggio devo cercare.

On Tue, 1 Sep 2020 at 14:34, Cascafico Giovanni  wrote:

> Il 31/08/20, Volker Schmidt ha scritto:
> > Ho guardato http://audit.osmz.ru/map/AM-IT#6/43.604/12.546
> > e ho trovato un albero a 300m di casa mia in un parco, ma la posizione
> > indicata è un prato non albareto dentro questo parco
> > Quale è la precisione di posizione dei dati?
>
> Puoi darmi le coordinate? Federico Cortese ed io stiamo controllando
> un po' in giro mi sembra che le coordinate siano piuttosto precise.
> Siccome il MIPAAF raccoglie li sopralluoghi dalle regioni, se hai
> trovato un errore nella tua può essere che sia un problema degli
> operatori in zona e che ci siano altri errori.
> Possiamo perciò verificare se l'errore è solo nella Google Map oppure
> anche negli excel regionali in calce alla parina [1]. Così magari
> eliminiamo una dell due fonti. Tra l'altro i campi di denotazione sono
> piuttosto diversi.
>
> [1]
> https://www.politicheagricole.it/flex/cm/pages/ServeBLOB.php/L/IT/IDPagina/11260
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Rond point et relations routes

2020-09-01 Thread Georges Dutreix via Talk-fr


Bonjour,

J'ai souvent découpé des giratoires pour des lignes de bus : honte sur moi !
Promis, je ne le ferai plus ;-)

Peut-être faudrait-il décrire les bonnes pratiques, pour les naïfs comme 
moi, dans des pages comme https://wiki.openstreetmap.org/wiki/FR:Bus
ou 
https://wiki.openstreetmap.org/wiki/FR:Relation:route#Les_itin.C3.A9raires_de_bus_et_les_ronds-points 
?


Je ne maîtrise pas assez celles-ci pour m'amuser à modifier le wiki 
moi-même. Et il semblerait qu'il n'y ait pas consensus...
Peut-on écrire par ci par là que la bonne pratique en France est de, si 
possible, ne pas casser les rond points en plusieurs segments ?




Le 01/09/2020 à 11:24, Yves P. a écrit :

Bonjour,

Je tombe sur des itinéraires vélos, bus… qui passent par des ronds-points.

Ces derniers sont coupés en petits morceaux pour avoir un bel itinéraire.
Ça part d'une bonne intention (j'ai fait la même chose au début), mais c'est 
ingérable !

S'il vous plait ne serez pas le sécateur quand vous croisez un giratoire.
Merci pour lui et son intégrité 

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


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

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

2020-09-01 Thread Minh Nguyen


Vào lúc 06:17 2020-09-01, Matthew Woehlke đã viết:
On a related note: I use service=driveway (for lack of anything better) 
for access ways to parking lots that don't have parking spaces (hence, 
not service=parking_aisle). These are likely *not* public right-of-ways 
(the lots themselves are usually "private"), but they are also certainly 
not access=private.


The access roads that form the backbone of a parking lot layout 
shouldn't be tagged service=driveway. [1] You're right that there isn't 
a more appropriate, well-established service=* tag, since no one seems 
to know of a concise, intuitive term for these access roads. But there's 
also no requirement that every highway=service way have a service=* tag. 
(Shared driveways also commonly lack service=*, but there are at least 
some tagging ideas floating about.)


Routers that understand service=driveway treat it as the very bottommost 
rung in a hierarchy of road classifications, applying penalties similar 
to the penalties for parking aisles. These penalties generally ensure 
you'd never use a driveway as a shortcut between two non-driveways. But 
around a parking lot, they may lead to suboptimal routing to a loading 
dock or drop-off area, traversing ordinary parking aisles instead of 
these access roads that are likely to be wider and more traversible.


If we do someday come up with a good tag for the access roads you're 
describing, it'll be easier to identify and retag them if they lack a 
service=* tag than if they're tagged service=driveway. After all, 
service=driveway would be more appropriate for a drop-off area coming 
off a parking lot. In the meantime, it's rather nice that some renderers 
and editors give service roads deemphasize service=parking_aisle ways 
while leaving these bare highway=service ways a little more prominent by 
comparison.


So, no, service=driveway should *not* imply 
access=private. If anything, lacking other information, it should imply 
access=yes just like it does on any other way, and I suspect routing 
engines route accordingly.


This is my understanding as well. It's OK that a router generally treats 
driveways as accessible: most driveways are dead-ends, so a router would 
only lead a delivery driver down a driveway if they have a package to 
deliver to that house. (Clearly Amazon's intention is to know how to go 
down the driveway instead of stopping at the curbside mailbox.) On the 
other hand, if the driveway isn't a dead end, a penalty should prevent 
it from being used as a Waze-style shortcut around a more easily 
traversible public road.


This, BTW, is a large part of why we're having this conversation in the 
first place. The problem with overusing access=private is that we're 
effectively teaching routing engines to ignore that, which makes such 
tagging much less useful.


Exactly. As a mapper, I'd be concerned about a logistics company such as 
Amazon needing to route to the front door, so to speak, and therefore 
tossing out a convenient way to distinguish between two common kinds of 
driveways that can't be used in the same manner.


Vào lúc 12:56 2020-08-31, Kevin Broderick đã viết:
> Second, I'd like to point out that there *are* driveways in New England
> that are actually public right-of-ways.
> https://www.openstreetmap.org/way/19685143
>  is one such example; the
> southernmost portion of the way is arguably service=driveway, except
> that it is actually a public right-of-way that continues south,
> eventually connecting to Lincoln Gap Road. While they are certainly the
> exception and not the rule, the number of such setups in Vermont is
> non-trivial due to the ancient roads laws there. There are probably some
> similar cases in New Hampshire and possibly Maine, I believe, but I
> can't cite any off the top of my head (the documentation of unmaintained
> public-right-of-ways isn't as good as it is in Vermont, making things a
> bit more murky).

Penalties aren't absolute prohibitions, so if there's no other way to 
get to that public road, or if the alternative would take much, much 
longer, the router will hold its nose and use the driveway. But it can't 
do that if the road is marked as impassable via access=no or restricted 
via access=private.


It can be a bit unintuitive to think about routing penalties when 
mapping. During a navigation mapping workshop at State of the Map 2018 
in Milan, my colleague Kajari and I walked through a very basic 
application of a routing penalty to illustrate the concept. The workshop 
wasn't recorded, but the notes and slides are available at [2], with the 
explanation starting on slide 12.


[1] 
[2] 



--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list

Re: [Talk-it] Edit automatici su nome strade

2020-09-01 Thread Martin Koppenhoefer



sent from a phone

> On 1. Sep 2020, at 10:15, Andrea Musuruane  wrote:
> 
> Questi mass edit, oltre a non essere concordati e non seguire le guidelines, 
> non hanno senso perché senza conoscenza del luogo non si può sapere se la 
> strada fosse intitolata a qualcun altro con lo stesso cognome.


sono d’accordo con te. Meglio lasciare le incertezze che indovinare.

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

Re: [OSM-talk-fr] Rond point et relations routes

2020-09-01 Thread Gad Jo

Pour avoir mis en place l'ensemble du réseau de bus sur Narbonne c'est la mort 
dans l'âme que j'ai du segmenter en plusieurs section des routes ou rue. C'est 
vite ingérable et pourtant j'ai tout le réseau en tête.
Pour les giratoire c'est totalement inutile de les segmenter sauf cas très très 
particulier. Le routage fonctionne très bien tel quel.

Avec les restrictions de vitesse, bande cyclable et autre info (trottoir, 
revêtement, éclairage) ça multiplie les découpes

Malheureusement je ne vois aucune solutions pour éviter cela.

Le September 1, 2020 9:44:37 AM UTC, Christian Rogel 
 a écrit :
>
>> Le 1 sept. 2020 à 11:25, Yves P.  a écrit :
>> Je tombe sur des itinéraires vélos, bus… qui passent par des
>ronds-points.
>> 
>> Ces derniers sont coupés en petits morceaux pour avoir un bel
>itinéraire.
>> Ça part d'une bonne intention (j'ai fait la même chose au début),
>mais c'est ingérable !
>> 
>> S'il vous plait ne serez pas le sécateur quand vous croisez un
>giratoire.
>> Merci pour lui et son intégrité 
>
>
>Déjà mentionné, mais, j’approuve cette piqûre de rappel. Il faut pour
>agir ainsi, soit appartenir à la team 1er degré, soit être certain que
>le RP est positionné correctement. Et surtout au bon diamètre.
>Eh, bien, non, ça n’existe qu’au pays de Gaston Lagaffe.
>Plusieurs fois, j’ai rétabli l’intégrité et, par respect pour les
>autres contributeurs, laissé dans l’état normal.
>
>Christian R.
>
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-cz] Import zastávek veřejné dopravy Jihočeského kraje

2020-09-01 Thread <0174

Ahoj,
já bych dal celý název do name. Na zastávkách je celý název obvykle psaný
(nevím jak je to se standardizací v Jihočeském kraji), příklad z JMK:
https://upload.wikimedia.org/wikipedia/commons/a/ab/Moravsk%C3%BD_Krumlov%2C_U_N%C3%A1dra%C5%BE%C3%AD%2C_autobusov%C3%A1_zast%C3%A1vka.jpg
A "on the ground" princip zrovna tohle udává jako příklad:
"Sometimes there's conflicting information about, say, the name of a place.
[...People...] need to find the names from local signs in the map [...]"
https://wiki.openstreetmap.org/wiki/Good_practice#Map_what.27s_on_the_ground

Pak je otázka, co se zkratkami, osobně bych dal do "name" rozepsaný název a
ten se zkratkami někam jinam (třeba do toho ref_name, i když o tom jsem se
dozvěděl až v tomto vlákně :) ).

<0174

út 1. 9. 2020 v 17:36 odesílatel Marián Kyral  napsal:

> Ahoj,
> co takhle official_name=* ? Nebo dát celý název do name= a zkrácený do
> short_name=.
>
> https://wiki.openstreetmap.org/wiki/Key:name
>
> Marián
>
> -- Původní e-mail --
> Od: majkaz 
> Komu: OpenStreetMap Czech Republic 
> Datum: 1. 9. 2020 17:15:48
> Předmět: Re: [talk-cz] Import zastávek veřejné dopravy Jihočeského kraje
>
> K těm názvům ve formátu ,<Část obce>,:
>
> Co s tím prakticky? Ten plný název bych dala do ref_name, tam to je
> jednoznačné a předpokládám, že se to tam očekává. Každý bod tak bude mít 
> "oficiální"
> a kompletní název, jen ho nebude mít v name.
>
>
> Ale co s name? Tam bych čekala to, co se běžně používá v řeči, hlásí v
> MHD, resp. použiji když si v autobuse budu kupovat jízdenku. K tomu se
> strojově moc nedá dostat, i když to je zpravidla 2. část názvu, pokud to
> nemá tu třetí část vyplněnou. Samozřejmě bych to mohla projet ručně, a do
> nějaké formy to upravit. Otázka je, jestli to má smysl, většinou to bude
> duplikovat název obce.
>
>
>
> Začínám se přiklánět k tomu, to u toho importu ignorovat, případně jen
> rozebrat jednoznačné případy tam, kde to má jen 1. a 3. část, a jiná
> varianta tam neexistuje. Tím by se postihla větší města, pokud už to tam
> nemáme zmapováno. U zbytku zastávek to pak nechat prázdné, a mít jen
> ref_name, opět pokud už v datech něco není.
>
>
>
> Majka
>
>
>
> __
> > Od: "Mikoláš Štrajt" 
> > Komu: "OpenStreetMap Czech Republic" 
> > Datum: 01.09.2020 16:23
> > Předmět: Re: [talk-cz] Import zastávek veřejné dopravy Jihočeského kraje
> >
>
>
>
>
> Zdar,
>
> k těm názvům autobusových zastávek mám připomínku:
>
>
>
> Názvy autobusových zastávek jsou definovány ve formátu souboru JDF, který
> se používá při importu do celostátní informačního systému o jízdních řádech
> (CIS), potažmo IDOSu.
>
>
>
> Ten formát názvu je následující:
>
>
>
> ,<Část obce>,. Povinná je jenom ta první část
> a naopak nemusí být vyplněna druhá část a naopak je vyplněná třetí.
>
>
> Tj. např. (pro Jihočeský kraj):
>
>
> - Drahotěšice (jenom jedna část)
> - Hosín, Dobřejovice, U smržů (všechny)
>
> - Lišov,Červený Újezdec (dvě části)
>
> - České Budějovice,,Pekárny (první a poslední - druhá je prázdná)
>
>
>
> Typicky se u spojů jedoucích pouze městem hlásí jenom ta poslední část,
> ale pro jednoznačnou identifikaci zastávky je někdy potřeba celý název
> (typicky když je to zastávka nazvaná ve stylu "České
> Budějovice,,aut.nádr.").
>
>
>
> Viz https://www.chaps.cz/cs/products/CIS a
> https://www.chaps.cz/files/cis/jdf-1.10.pdf
>
>
>
> zdraví
>
> --
>
> Severák
>
>
>
> ___
> 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
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[OSM-talk-fr] Les courée de Roubaix : adresse et entrée

2020-09-01 Thread Denis Chenu via Talk-fr

Bonjour,

Je suis en train de reprendre les adresses du Fantoir et de les ajouter
sur Roubaix.
Les adresses non encore répertorié sont souvent les courées :
https://fr.wikipedia.org/wiki/Cour%C3%A9e

Sur le Fantoir : en général elles ont la double adresse:
«Nom de courée Nom de la Rue»

Lors de l'envoi postal, certains utilisent la double adresse
1 Courée nom de la Couré
42 rue de la rue

Selon le BANO, j'ajoute ou non le nom de la rue.
Mais je me pose la question de la double adresse ?
Est-ce qu'il peut être intéressant d'indiquer une deuxième ligne ?
Est sou quel format , quel tag utiliser ?
peut être addr:full : https://wiki.openstreetmap.org/wiki/Key:addr:full ?


Autre chose : ces courées ont des entrées qui appartiennent à la rue
principale.

Je me pose la question d'ajouter ces entrées puis de les ajouter à la
relation ?
Ici : une entrée que j'ai taggué :
https://www.openstreetmap.org/node/7864474720

En image : ce que peux donner une entrée
https://pic.infini.fr/L69zoN2N/kiVHull9.png (ici c'est celle ci dessus)
ou
https://pic.infini.fr/7iDxlOYf/KMge9ehI.png

Cela est intéressant ? je continu (et ajoute les précédentes) ? Je les
ajoute dans la relation ?

Merci,
Denis



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

[Talk-us] New Hampshire Perambulations

2020-09-01 Thread Russell Nelson

New Hampshire has a law requiring the town council of every town to hike 
the perimeter of the town once every seven years. They can appoint an 
agent to do it. I did one of these hikes, between Henniker and Weare. 
There are markers along the way, which we re-painted, or otherwise 
renewed. Regardless of what any map says, these markers are the borders 
of the town, and can only be ascertained by a hike.



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

Re: [talk-cz] Import zastávek veřejné dopravy Jihočeského kraje

2020-09-01 Thread Marián Kyral


Ahoj,

co takhle official_name=* ? Nebo dát celý název do name= a zkrácený do short
_name=.





https://wiki.openstreetmap.org/wiki/Key:name




Marián



-- Původní e-mail --
Od: majkaz 
Komu: OpenStreetMap Czech Republic 
Datum: 1. 9. 2020 17:15:48
Předmět: Re: [talk-cz] Import zastávek veřejné dopravy Jihočeského kraje
"
K těm názvům ve formátu ,<Část obce>,:

Co s tím prakticky? Ten plný název bych dala do ref_name, tam to je
jednoznačné a předpokládám, že se to tam očekává. Každý bod tak bude mít 
"oficiální" a kompletní název, jen ho nebude mít v name.




Ale co s name? Tam bych čekala to, co se běžně používá v řeči, hlásí v MHD,
resp. použiji když si v autobuse budu kupovat jízdenku. K tomu se strojově
moc nedá dostat, i když to je zpravidla 2. část názvu, pokud to nemá tu
třetí část vyplněnou. Samozřejmě bych to mohla projet ručně, a do nějaké
formy to upravit. Otázka je, jestli to má smysl, většinou to bude duplikovat
název obce.

 

Začínám se přiklánět k tomu, to u toho importu ignorovat, případně jen
rozebrat jednoznačné případy tam, kde to má jen 1. a 3. část, a jiná
varianta tam neexistuje. Tím by se postihla větší města, pokud už to tam
nemáme zmapováno. U zbytku zastávek to pak nechat prázdné, a mít jen ref_
name, opět pokud už v datech něco není.

 

Majka

 

__
> Od: "Mikoláš Štrajt" 
> Komu: "OpenStreetMap Czech Republic" 
> Datum: 01.09.2020 16:23
> Předmět: Re: [talk-cz] Import zastávek veřejné dopravy Jihočeského kraje
>



 

Zdar,

k těm názvům autobusových zastávek mám připomínku:

 

Názvy autobusových zastávek jsou definovány ve formátu souboru JDF, který se
používá při importu do celostátní informačního systému o jízdních řádech
(CIS), potažmo IDOSu.

 

Ten formát názvu je následující:

 

,<Část obce>,. Povinná je jenom ta první část  a
naopak nemusí být vyplněna druhá část a naopak je vyplněná třetí.





Tj. např. (pro Jihočeský kraj):





- Drahotěšice (jenom jedna část)
- Hosín, Dobřejovice, U smržů (všechny)


- Lišov,Červený Újezdec (dvě části)


- České Budějovice,,Pekárny (první a poslední - druhá je prázdná)


 

Typicky se u spojů jedoucích pouze městem hlásí jenom ta poslední část, ale
pro jednoznačnou identifikaci zastávky je někdy potřeba celý název (typicky
když je to zastávka nazvaná ve stylu "České Budějovice,,aut.nádr.").

 

Viz https://www.chaps.cz/cs/products/CIS a https://www.chaps.cz/files/cis/
jdf-1.10.pdf

 

zdraví

--

Severák

 

___
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-cz] Import zastávek veřejné dopravy Jihočeského kraje

2020-09-01 Thread majkaz

K těm názvům ve formátu ,<Část obce>,:
Co s tím prakticky? Ten plný název bych dala do ref_name, tam to je jednoznačné a
předpokládám, že se to tam očekává. Každý bod tak bude mít "oficiální" a
kompletní název, jen ho nebude mít v name.

Ale co s name? Tam bych čekala to, co se běžně používá v řeči, hlásí v MHD,
resp. použiji když si v autobuse budu kupovat jízdenku. K tomu se strojově moc
nedá dostat, i když to je zpravidla 2. část názvu, pokud to nemá tu třetí část
vyplněnou. Samozřejmě bych to mohla projet ručně, a do nějaké formy to upravit.
Otázka je, jestli to má smysl, většinou to bude duplikovat název obce.
Začínám se přiklánět k tomu, to u toho importu ignorovat, případně jen rozebrat
jednoznačné případy tam, kde to má jen 1. a 3. část, a jiná varianta tam
neexistuje. Tím by se postihla větší města, pokud už to tam nemáme zmapováno. U
zbytku zastávek to pak nechat prázdné, a mít jen ref_name, opět pokud už v
datech něco není.
Majka
__

Od: "Mikoláš Štrajt"
Komu: "OpenStreetMap Czech Republic"
Datum: 01.09.2020 16:23
Předmět: Re: [talk-cz] Import zastávek veřejné dopravy Jihočeského kraje

Zdar,
k těm názvům autobusových zastávek mám připomínku:
Názvy autobusových zastávek jsou definovány ve formátu souboru JDF, který se
používá při importu do celostátní informačního systému o jízdních řádech (CIS),
potažmo IDOSu.
Ten formát názvu je následující:

,<Část obce>,. Povinná je jenom ta první část a
naopak nemusí být vyplněna druhá část a naopak je vyplněná třetí.

Tj. např. (pro Jihočeský kraj):

- Drahotěšice (jenom jedna část)
- Hosín, Dobřejovice, U smržů (všechny)

- Lišov,Červený Újezdec (dvě části)

- České Budějovice,,Pekárny (první a poslední - druhá je prázdná)

Typicky se u spojů jedoucích pouze městem hlásí jenom ta poslední část, ale pro
jednoznačnou identifikaci zastávky je někdy potřeba celý název (typicky když je to
zastávka nazvaná ve stylu "České Budějovice,,aut.nádr.").
Viz https://www.chaps.cz/cs/products/CIS a
https://www.chaps.cz/files/cis/jdf-1.10.pdf
zdraví
--
Severák

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

Re: [Talk-us] Trouble with getting Superior National Forest

On Tue, Sep 1, 2020 at 9:03 AM Frederik Ramm  wrote:

> On 01.09.20 14:40, Kevin Kenny wrote:
> > We don't map cadastre at least partly out of respect for personal
> > privacy - something that is not at issue with government-owned land.
>
> I think I'm with Joseph here, we don't map cadastre stuff also because
> it makes no sense for us to become a copy of data that is
> authoritatively kept elsewhere. OSM's strength is that data can be
> edited by everybody based on observations. Data for which the sentence
> "if you edit this it will become wrong" is true should not be in OSM.
>

In my area, I deal with - and have imported - several 'authoritative' data
sets, and I personally do _not_ consider them all that authoritative, since
they are digitizations of descriptions of what is in the field. (Our land
title does not work by latitude and longitude; the authoritative reference
is a verbal description of the 'metes and bounds' - the physical objects in
the field that define the property line. A land surveyor must recover those
objects in order to do a formal survey of the line; generally speaking, the
surveyors choose or make marks that will last for decades or centuries, and
make redundant marks so that a line can be struck from partial recovery.)
They're quite often some distance away from reality.

I deal routinely with cases where there is public land managed by different
authorities, with shared boundaries. The boundaries very seldom align, and
occasionally are far off.

In many of these cases OSM has an opportunity to improve the government
data.  A mapper can analyze the conflict, sort out the different data
sources, perhaps visit the site in the field, and produce a result that is
more accurate than any of the government data sets. It's been pretty quiet,
but I know that there some corrections from OSM have flowed back into some
of the government data sets that I use.

A handful of particular examples:

https://www.openstreetmap.org/user/ke9tv/diary/391486 - reconstructing a
town line by comparison of old maps from the Federal government (three
versions of the USGS topo maps), the State government (the topo maps from
the State department of transportation, wilderness boundaries from the
Department of Environmental Conservaion, tax plats from two counties, and
historic maps of the old Dutch land grants.

https://www.openstreetmap.org/user/ke9tv/diary/42951 - clarifying the
boundary between a State Park and a military reservation - needed to warn
hikers of trespassing - which was incorrect in *all* available data sources
and needed some field work to recover.

(no diary entry) Unifying the boundaries of the West Point military
reservation https://www.openstreetmap.org/relation/175474 with the
surrounding lands, which include three state parks, a protected forest
belonging to an NGO, a cemetery, a golf course, and several transportation
corridors. The boundaries of all these objects had been previously on the
map from other imports and from hand-mapping - and conspicuously failed to
align. The data from the US Government were perhaps the worst of the lot -
and in fact, I got conflicting data from multiple agencies. I'm still not
100% sure of the totality of the boundary - it's a massive project - but
the very worst inconsistencies did indeed have their corners verified in
the field. (Every so often, someone, without discussion, reimports one or
another government data set on top of this hard work, and I'm grateful to
the DWG for the times that they've helped me get it sorted again.) One
thing that was particularly satisfying about this one is that Black Rock
Forest had previously been a blank spot on the map. I heard from a local
mapper who had learnt about its existence from OSM - and within a few
months after I added the boundary, he and others had filled in quite a lot
of detail within it!

(no diary entry again) I've revised the boundaries of a number of the
Wilderness and Wild Forest areas in the Adirondacks, because they clearly
were following natural features, and were misaligned to those features
(e.g., islands in the lakes).  That's gone as far as to remove one boundary
line from the Lake George Islands property because that island itself was
destroyed in a storm some years ago. (The State GIS people had simply not
got around to making the change.)

(no diary entry) OSM had, more or less correctly, the expansion of the High
Peaks Wilderness https://www.openstreetmap.org/relation/6360488 into the
area around the Boreas Ponds about six months before the state GIS
department released the updated data set.  I entered it by obtaining copies
of the tax plats of the former Finch Pruyn company, and hand-digitizing the
areas that had been transferred to New York State.  (I reconciled the
differences when they did; I didn't leave my interim lines in place.)

In your criticisms of imports, you often describe them as dead data. I
don't agree.  In fact, any time I've done an import, it's because I want

[OSM-talk-fr] Fwd: Des nouvelles de transport.data.gouv.fr ! | Info-lettre Août 2020

Des nouvelles de transport.data.gouv.fr !
Des nouvelles du Point d'Accès National aux données de transport !
Bonjour à toutes et à tous,

L'été touche à sa fin et la rentrée arrive avec son lot de nouveaux
chantiers ! Nous avons cet été pu concentrer nos efforts sur le
développement de nouvelles fonctionnalités et l'élaboration de nouveaux
schémas pour des données d'intérêt comme les aménagements cyclables ou
l'autopartage. La période de la rentrée se prête également à la mise à jour
des données d'horaires théoriques ; nous vous invitons à participer à notre
prochain atelier le 8 septembre sur ce sujet (détails en bas de
l'info-lettre).
*☀ *Un été de nouvelles fonctionnalités !

*Le nouveau validateur de données*

Garantir la qualité des jeux de données du Point d'Accès National, c'est
proposer des outils pour mieux comprendre les erreurs qu'ils peuvent
contenir. Une visualisation géographique est désormais disponible sur les
défauts que notre Validateur

 identifie dans les fichiers GTFS. Qu'il s'agisse de temps de trajets nuls
entre deux stations, d'arrêts trop proches, en double, inutilisés... tous
ces problèmes sont désormais visualisables sur une carte.


*La carte nationale des réseaux de transports sur le Point d'Accès National*

Petite nouveauté parmi les jeux de données édités par transport.data.gouv.fr
: un extract pour toute la France de la position des arrêts et des tracés
des lignes

de
tous les jeux de données de transports en commun disponibles sur la
plateforme. Nous vous avions présenté dans la Newsletter de Juin notre
outil d'extraction automatique des géométries des jeux de données GTFS. Ce
fichier national est la simple agrégation de tous les fichiers GeoJSON qui
avaient été ainsi générés. Attention : cette méthode peut créer des doublons
certaines stations étant présentes dans différents jeux de données !
* *Une rentrée à vélo
*De nouveaux schémas pour les données d'aménagements et stationnements
cyclables.*

L'une des activités de l'été a été de travailler sur l’élaboration d'un schéma
national pour les données concernant les aménagements cyclables (bandes et
pistes cyclables...) et le stationnement des vélos (arceaux et autres
dispositifs). C'est une thématique qui suscite beaucoup d'engagements et
nous avons pu bénéficier de la motivation de producteurs et de
réutilisateurs de données !

Un schéma de données a été établi lors du quatrième atelier sur
l'harmonisation des données d'infrastructures cyclables
.
Il a été défini grâce au travail initié par Vélo & Territoires

et au groupe de travail composé de producteurs et réutilisateurs de données.
Vous trouverez ici le schéma retenu : lien

.

Nous travaillons actuellement sur :

   - L’établissement du dictionnaire de données ;
   - La mise en place d’une photothèque pour les différents types
   d’aménagements cyclables référencés.

Si vous voulez contribuer à cette définition et illustration des données
d'aménagements cyclables, vous pouvez Miryad, en charge de l'investigation
de ces données à cette adresse : miryad@beta.gouv.fr.

Par ailleurs un travail d'investigation a été mené sur les données de
stationnement
vélo. A partir de l'analyse des données locales publiées sur de nombreux
portails et des données présentes sur OpenStreetMap, un schéma de données a
été proposé pour standardiser la publication de ce type de données. Un espace
de discussion

a été créé sur le projet Github de schema.data.gouv.fr. Nous vous
encourageons vivement à regarder ce schéma

et proposer des modifications si nécessaire !

* *Des chiffres sur notre déploiement *Quelques statistiques pour mieux
suivre l'avancement du projet transport.data.gouv.fr
*


Nous vous proposerons désormais à chaque Newsletter un petit aperçu
statistique de l'état d'avancement du projet.

 Nos futurs rendez-vous

   - *Mardi 8 septembre *- atelier pour les producteurs de données sur la
   gestion de leurs mises à jour.

Cet atelier permettra de donner des outils et conseils pour anticiper

Re: [talk-cz] Import zastávek veřejné dopravy Jihočeského kraje

2020-09-01 Thread Mikoláš Štrajt


-- Původní e-mail --
Od: Jan Martinec 
Komu: OpenStreetMap Czech Republic 
Datum: 1. 9. 2020 11:44:06
Předmět: Re: [talk-cz] Import zastávek veřejné dopravy Jihočeského kraje
"Ahoj,

> Dala bych dohromady import. Odkaz na zdroj dat bych dala jen k
> sadě/sadám změn. Přísně vzato by se nejednalo o import, ale o vložení
> dat na základě těch informací, udělala bych tomu jednotlivě ještě ruční
> kontrolu.

to zní jako super nápad, jen mám připomínku k těm názvům:

> číslo > ref:JCK - případně otázka, zda vůbec přidávat

Rozhodně ano, chleba to nežere, a ref_name není tesaný do kamene
(přejmenování ulice etc.).

> * u zastávek typu "Kovářov,Žebrákov,rozc.0.1" vzít část mezi čárkami,
> tj. "Žebrákov" jako name, nebo nechat prázdné

Tím vzniknou duplicitní názvy - některé obce mají zastávku "Xyz, rozc.
0.5" na silnici, a pak ještě "Xyz" v obci, do které ale zajíždí méně
spojů. (V bizarnějších případech pak více zastávek "...rozc.[X.Y]")
Prostě bych tu zahazoval jen tu část před první čárkou."



Zdar,

k těm názvům autobusových zastávek mám připomínku:




Názvy autobusových zastávek jsou definovány ve formátu souboru JDF, který se
používá při importu do celostátní informačního systému o jízdních řádech
(CIS), potažmo IDOSu.




Ten formát názvu je následující:





,<Část obce>,. Povinná je jenom ta první část  a
naopak nemusí být vyplněna druhá část a naopak je vyplněná třetí.





Tj. např. (pro Jihočeský kraj):





- Drahotěšice (jenom jedna část)
- Hosín, Dobřejovice, U smržů (všechny)


- Lišov,Červený Újezdec (dvě části)


- České Budějovice,,Pekárny (první a poslední - druhá je prázdná)





Typicky se u spojů jedoucích pouze městem hlásí jenom ta poslední část, ale
pro jednoznačnou identifikaci zastávky je někdy potřeba celý název (typicky
když je to zastávka nazvaná ve stylu "České Budějovice,,aut.nádr.").





Viz https://www.chaps.cz/cs/products/CIS a https://www.chaps.cz/files/cis/
jdf-1.10.pdf




zdraví


--


Severák



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

Re: [Talk-de] Maß für die Genauigkeit von Eigenbau-GPS-Geräten?

2020-09-01 Thread Heinz-Jürgen Oertel

Am Dienstag, 1. September 2020, 12:10:56 CEST schrieb Manuel Reimer:
> Das wäre dann die nächste Frage: Wo könnte man das dokumentieren. 

gitLab ?

als vergleich:
https://gitlab.com/slepp/arduino-gps-logger

Auf solchen Repositories kann man durchaus hard- und software projekte hosten


Heinz




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

Re: [Talk-us] Trouble with getting Superior National Forest

2020-09-01 Thread Bradley White

>Protect area and National Park boundaries were supposed to be less difficult 
>to confirm and more valid.

The NF administrative boundaries are basically impossible to verify
on-the-ground if that's the standard we are setting to demonstrate
verifiability. Typically, the only indication are the large welcoming
signs placed adjacent to major highways running through NF land, and
even then these typically aren't placed exactly on these boundaries.
For example, the administrative boundary for the Humboldt-Toiyabe NF
includes half the city of Reno, but none of this urban land is
protected at all, and there is zero on-the-ground indication of this
boundary.

> But if what we are going to start mapping in the USA is simply the federal 
> ownership of land, that's just pure cadastre data. We might as well try to 
> map all the private land parcels and keep that information accurate - but 
> both tasks are too difficult, and the data is better provided by local 
> governments directly.

I think this is a bit of a slippery slope argument. At least in
California, the NF land ownership boundaries are public record with no
copyright (https://wiki.openstreetmap.org/wiki/Contributors#United_States).
The boundaries of the federally-owned parcels *are* the protected
areas - you can't accurately map them without the parcel data here.
Using this data doesn't mean we have to start importing county parcel
data carte blanche.

If we shouldn't use land ownership because this relies on parcel data,
and the reason we don't use parcel data is because it is subject to
change and generally unverifiable on-the-ground, then we really
shouldn't be using NF administrative boundaries either since they are
likewise imported from easily accessed government data sources,
subject to change, and unverifiable on-the-ground.

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

Re: [Talk-us] Opinions on Devil's Slide Bunker (San Mateo, CA)

2020-09-01 Thread Brian Stromberg

OSM comprises data but data are produced and interpreted by fallible
humans. I would argue that OSM doesn't "simply say" anything, because the
act of defining tags is a subjective process negotiated between individuals
with different ideas about, for example, what a "viewpoint" is. It's not a
simple matter of recording altitude or what type of rock formation is in a
location. We are defining what a lot of these data will be and how they
will be communicated through OSM to the users, and that has an impact on
how those users interpret the world. There's a certain amount of
responsibility inherent to that process. And if we are going to take the
tactic of simply putting "what is" on the map, then I would argue we should
only include viewpoints that are officially signed as such. Otherwise the
process of deciding which ones are included and which ones are becomes too
subjective and will never accurately reflect "what is".

I think Kevin provides a lot of really good examples of edge cases that
make a blanket rule difficult to develop, I appreciate you sharing them.
Creative usage of tagging might be the best way to approach those types of
situations, although I wonder how many OSM users will use that metadata, as
opposed simply looking at the locations on a map. The stories also speak to
the idea that people will find these places even if they aren't on OSM, and
it makes me wonder if OSM needs to include every trail and viewpoint known
to man (especially the story of the city folk being turned back for safety
concerns).

Sidenote: this discussion is such a great example of complicated it is to
produce a map, I'm very much enjoying it.

--
Brian

On Tue, Sep 1, 2020 at 2:33 AM Mateusz Konieczny via Talk-us <
talk-us@openstreetmap.org> wrote:

>
>
>
> 31 Aug 2020, 05:38 by stevea...@softworkers.com:
>
> On Aug 30, 2020, at 5:50 PM, Brian Stromberg 
> wrote:
>
> I would argue that maps can only show the world as the mapmaker wants it
> to be shown, and OSM should probably not be encouraging people (in any way)
> to be visiting sites that are clearly marked as illegal to visit. This
> seems like a bad precedent to set. I would include the bunker but not mark
> it as tourism. People will find it if they want to, whatever OSM tags it
> as, so it doesn't seem necessary to participate/encourage in whatever
> degree of illegality the access entails.
>
>
> And here is where some disagree: OSM does not "encourage." OSM is data. It
> simply says "this is" and "these are." OSM does not encourage people (in
> any way) to visit a site or trespass. It is a collection of data (of "what
> is") expressed as a map. Full stop.
>
> At the same time we know that viewpoint
> data can be used, is used and it's typical
> use is to display interesting locations
> worth visiting.
> ___
> 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

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

2020-09-01 Thread Matthew Woehlke


On 31/08/2020 15.56, Kevin Broderick wrote:

First, I'd like to point out that this discussion started off with the
question of removing "access=private" from Amazon-logistics-mapped
driveways. I still maintain that the mechanical edit would be a good thing,
because the tagging as added is based on an assumption that
service=driveway implies access=private, which (a) isn't 100% accurate, and
(b) adds the appearance of more detail in the database without actually
adding any value (i.e. if it is a safe assumption, then adding the tag is
superfluous; if it isn't, then adding it is potentially misleading).

Second, I'd like to point out that there *are* driveways in New England
that are actually public right-of-ways.


On a related note: I use service=driveway (for lack of anything better) 
for access ways to parking lots that don't have parking spaces (hence, 
not service=parking_aisle). These are likely *not* public right-of-ways 
(the lots themselves are usually "private"), but they are also certainly 
not access=private. So, no, service=driveway should *not* imply 
access=private. If anything, lacking other information, it should imply 
access=yes just like it does on any other way, and I suspect routing 
engines route accordingly.


This, BTW, is a large part of why we're having this conversation in the 
first place. The problem with overusing access=private is that we're 
effectively teaching routing engines to ignore that, which makes such 
tagging much less useful.


--
Matthew

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

Re: [Talk-us] Trouble with getting Superior National Forest

On Tue, Sep 1, 2020 at 12:52 AM Bradley White 
wrote:

>  If you drive into a checkerboard
>> area of private/public land, there are no Forest Service signs at the
>> limits of private land.
>>
>
> In my neck of the woods, USFS owned land is signed fairly frequently with
> small yellow property markers at the boundaries.
>

In repeated discussions about the large government-owned mixed-public-use
land areas in the US, people have argued repeatedly that the boundaries are
unverifiable.  We've shown references like
https://www.fs.usda.gov/detail/gwj/specialplaces/?cid=stelprdb5276999
indicating
that the boundaries are indeed marked, and how they are marked.

Note that that reference distinguishes the proclaimed boundary - the large
region in which the Congress has authorized the National Forest to exist -
from the actual forest land.

Maps commonly show proclaimed national forest boundaries. However, all land
> within these boundaries is not national forest land; some is privately
> owned. The user is cautioned to comply with state law and owner's rules
> when entering onto private land.

This has failed to satisfy. The same individuals continue to contend, each
time the topic comes around, that the boundaries are unverifiable, and to
cling to that contention in the face of this evidence. In a previous round,
one of the people actually advanced the argument that only each individual
sign, blaze, stake or cairn is verifiable, and that the line that they mark
is not verifiable and ought not to be mapped.

This behaviour convinced me long ago that there is a certain contingent
here, almost entirely comprising people who've never set foot in a National
Forest, who ardently wish to keep US National Forests and similar lands
(e.g., the zoo of New York State public-access areas, the Pennsylvania
State Game Lands, and even our State Parks) off the map, for reasons that
don't touch on verifiability, but throw verifiability into the pot in an
effort to make a stronger case.
-- 
73 de ke9tv/2, Kevin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trouble with getting Superior National Forest

2020-09-01 Thread Frederik Ramm

Hi,

On 01.09.20 14:40, Kevin Kenny wrote:
> We don't map cadastre at least partly out of respect for personal
> privacy - something that is not at issue with government-owned land. 

I think I'm with Joseph here, we don't map cadastre stuff also because
it makes no sense for us to become a copy of data that is
authoritatively kept elsewhere. OSM's strength is that data can be
edited by everybody based on observations. Data for which the sentence
"if you edit this it will become wrong" is true should not be in OSM.

> A larger point, however, is that we _do_ map land use; we _do_ map
> protection status, and we _do_ map constraints on public access.  In
> this particular case, as with many cases of government-owned land, the
> land use, the protection status, and the public access all follow the
> property lines. That is what is (implicitly) being mapped; mapping the
> property line is the way that it is achieved. 

I am wary of this line of reasoning because it will in many cases lead
to doing exactly what I write above, making a low-quality copy of
authoritative data that is kept elsewhere.

Bye
Frederik

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

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

Re: [Talk-GB] NCN 231 and NCN 235 Isle of Wight

2020-09-01 Thread Richard Fairhurst

[apologies for broken threading, Nabble is still down]

Jon Pennycook wrote:
> https://www.openstreetmap.org/relation/2821036 and
> https://www.openstreetmap.org/relation/2821037 (claiming to be
> National Cycle Network Route 231 and 235) have been listed on
> OpenStreetMap for some time. They appear to mostly duplicate
> Regional Cycle Network route 67
> (https://www.openstreetmap.org/relation/2742) aka "Round The Island"
> or "Taste the Wight".

Around 10 years ago, most (but not all) regional routes were
renumbered to become National Routes. NCN numbers 231 and 235 were
assigned to the RR67/Round the Island route as part of this.

As part of the NCN review underway, the route has now been dropped
from the NCN entirely, due to high motor traffic levels on some
sections.

I'd suggest deleting these two NCN relations and keeping the RR67
relation, though with the expectation that the latter may need to be
retagged if/when the Regional Route number is lost.

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

[OSM-talk-fr] Projet du mois : la presse comme source de données

Bonjour,

La recherche "défibrillateur dae" dans Google News permet de trouver des 
articles concernant l'installation de nouveaux DAE, ou leur utilisation.
La plupart indiquait des DAE inconnus GeoDAE et d'OSM.

Avis aux contributeurs qui aimeraient continuer, je me suis arrêté au 8 juin : 
Près de Dieppe, le stand de tir s’équipe d’un défibrillateur 


Peut-être que Twitter permettrait d'en trouver ?

__
Yves





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

Re: [Talk-GB] NCN 231 and NCN 235 Isle of Wight

2020-09-01 Thread Mateusz Konieczny via Talk-GB

Iff it is not existing then it should be deleted.

It is easy to do it in JOSM (after one 
passes hurdle if doing anything in JOSM)


1 Sep 2020, 11:52 by jpennyc...@bcs.org.uk:

> Hello.
>
> https://www.openstreetmap.org/relation/2821036>  and > 
> https://www.openstreetmap.org/relation/2821037>  (claiming to be National 
> Cycle Network Route 231 and 235) have been listed on OpenStreetMap for some 
> time. They appear to mostly duplicate Regional Cycle Network route 67 (> 
> https://www.openstreetmap.org/relation/2742> ) aka "Round The Island" or 
> "Taste the Wight". 67 is shown on the SusTrans OS Map, but 231 and 235 are 
> not. 
> The only NCN signs I have ever seen on the Isle of Wight are for 22 and 23. I 
> can't find any original sources thst mention either 232 or 235 (they are 
> mentioned in passing in the Wikipedia article on the NCN). I suspect someone 
> worked out a proposed route that was never approved, but it got into OSM 
> anyway. 
>
>
> What should I/we do? E.g.
> * Mark 231 and 235 as "Proposed"?
> * Delete both relations? How can this be done easily? 
>
> Jon 
>
>
>___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-us] Trouble with getting Superior National Forest

On Tue, Sep 1, 2020 at 3:18 AM Joseph Eisenberg 
wrote:

> The OpenStreetMap community has long agreed that mapping cadastral parcels
> (land ownership) is not in scope. Protect area and National Park boundaries
> were supposed to be less difficult to confirm and more valid.
>
> But if what we are going to start mapping in the USA is simply the federal
> ownership of land, that's just pure cadastre data. We might as well try to
> map all the private land parcels and keep that information accurate - but
> both tasks are too difficult, and the data is better provided by local
> governments directly.
>

We don't map cadastre at least partly out of respect for personal privacy -
something that is not at issue with government-owned land.

A larger point, however, is that we _do_ map land use; we _do_ map
protection status, and we _do_ map constraints on public access.  In this
particular case, as with many cases of government-owned land, the land use,
the protection status, and the public access all follow the property lines.
That is what is (implicitly) being mapped; mapping the property line is the
way that it is achieved.
-- 
73 de ke9tv/2, Kevin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Alberi monumentali d’Italia

2020-09-01 Thread Cascafico Giovanni

Il 31/08/20, Volker Schmidt ha scritto:
> Ho guardato http://audit.osmz.ru/map/AM-IT#6/43.604/12.546
> e ho trovato un albero a 300m di casa mia in un parco, ma la posizione
> indicata è un prato non albareto dentro questo parco
> Quale è la precisione di posizione dei dati?

Puoi darmi le coordinate? Federico Cortese ed io stiamo controllando
un po' in giro mi sembra che le coordinate siano piuttosto precise.
Siccome il MIPAAF raccoglie li sopralluoghi dalle regioni, se hai
trovato un errore nella tua può essere che sia un problema degli
operatori in zona e che ci siano altri errori.
Possiamo perciò verificare se l'errore è solo nella Google Map oppure
anche negli excel regionali in calce alla parina [1]. Così magari
eliminiamo una dell due fonti. Tra l'altro i campi di denotazione sono
piuttosto diversi.

[1] 
https://www.politicheagricole.it/flex/cm/pages/ServeBLOB.php/L/IT/IDPagina/11260

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

Re: [Talk-GB] ISO 3166-2:GB

2020-09-01 Thread Ed Loach

The values seem to be in OSM in the ISO3166-2 tag (a couple twice)

https://taginfo.openstreetmap.org.uk/keys/ISO3166-2#values

 

I tried to get overpass turbo to display them but I either got a timeout or a 
very large amount of data returned. I zoomed in and got GB-ENG, GB-ESS, GB-SOS 
and whatever Suffolk is (GB-SFK) showing, but Suffolk seemed to be under 
England so I couldn’t click on it. I removed ways and nodes from the gather 
generated by the wizard and increased the timeout to get

 

[out:json][timeout:55];

// gather results

(

  // query part for: “"ISO3166-2"=*”

  relation["ISO3166-2"]({{bbox}});

);

// print results

out body;

>;

out skel qt;

 

Ed

 

From: Steve Pointer 
Sent: 26 August 2020 18:19
To: Talk-GB 
Subject: [Talk-GB] ISO 3166-2:GB

 

Hi

 

Is there a OSM overlay map of any type that shows the Second-level subdivisions 
as outlied in ISO_3166-2:GB

 

So that would be:

 


Code

Subdivision name (en  )

Subdivision category

Parent subdivision


GB-BKM

Buckinghamshire  

two-tier county

  ENG


GB-CAM

Cambridgeshire  

two-tier county

  ENG


GB-CMA

Cumbria  

two-tier county

  ENG


GB-DBY

Derbyshire  

two-tier county

  ENG


GB-DEV

Devon  

two-tier county

  ENG


GB-DOR

Dorset  

two-tier county

  ENG


GB-ESX

East Sussex  

two-tier county

  ENG


GB-ESS

Essex  

two-tier county

  ENG

...

 

And so on?

 

Many Thanks

Steve P

 

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

Re: [OSM-talk-fr] Rond point et relations routes

Il y a quelques exceptions connues pour certains giratoires avec des
sections très différentes (certaines parties qui sont des ponts ou ayant
des restrictions spécifies avec des changements de voies).

La plupart des ronds-points son homogènes et ne nécessite aucun découpage
(et surtout pas pour les lignes de bus: le rond point reste entier et sur
les parcours est vu comme un point unique même si en zoomant on voit une
boucle à la place du point sur les diagrammes.

Le découpage est très rarement nécessaire. J'ai vu quelques exemples où ça
se justifie pour de très grands ronds-points multiniveaux (par exemple un
rond-point au dessus de la rocade sud de Rennes, car il n'y a pas moyen
d'unifier les tags dessus sans créer d'anomalies sur les autres voies qui
passent dessous ou transitent dessus, ni moyen de positionner correctement
les barrières de protection). Cependant le découpage est réduit au minimum,
juste pour les tags qui doivent changer de valeur sur certaines sections.
Et c'est parce que les tags actuellement approouvés et reconnus ne
permettant pas de faire facilement autrement. Ce cas est trop exceptionnel
pour justifier de façon suffisante une demande de modification de la
documentation et des usages. Parfois un nouveau tag règle le problème et
permet d'annuler un tel découpage.

D'une façon générale aussi j'enlève ces découpages qui le plus souvent ont
cassé les routes (sauf certaines des lignes qui y passent). Par exemple
quand il y a une voie centrale de bus qui traverse le rond-point, et des
deux ou arrêts sur la boucle. Cela ne concerne de toute façon que les très
grands-ronds-points (plus de 75 mètres de diamètre), et sinon beaucoup de
ronds-points en Angleterre (avec des deux et stops sur la boucle) et aux
USA (parfois des règles plus compliquées (même sur les
"turbo-roundabounts", sensés "optimiser" le traffic en donnant plus de
priorités à certaines voies traversantes ou certains tourne-à-gauche mais
en ajoutant là encore des cédez le passages et stop rapprochés ou
successifs pour entrer dans la boucle, et parfois même des impossibilités
d'aller d'une direction à une autre alors que ces directions sont sur des
voies bidirectionnelles: il faut rejoindre un autre rond-point
suivantet faire des kilomètres en plus).

Il y a d'autres exceptions dans des ronds-points géants en Asie, et
certains ronds-points en montagne (avec des sections de la boucle dans des
tunnels, d'autres sur des ponts, d'autres de plein-pied), on en voit près
d'Andorre, en Suisse et certaines villes côtières italiennes, là c'est
compliqué aussi par la coexistence d'autres réseaux, ferroviaires par
exemple, parfois aussi des canaux, des passerelles piéton, ça se superpose
sur divers niveaux), et dans les ronds-points d'interconnexion
autoroutières aux USA qui n'ont rien en commun avec nos giratoires français
habituels (qui font plus de la moitié de tous les ronds-points du monde, et
il s'en construit encore massivement, nombre de communes les utilisent pour
enlever les feux et réduire la pollution, le bruit, les accidents, et comme
moyen de réduire la vitesse).

Une exception connue en France est le rond-point de l'étoile en haut des
Champs-Elysée: un "rond-point" peut être mais pas du tout un "giratoire"
car avec des arrêts imposés au milieu de la boucle ou pour en sortir et des
restrictions pour les changements de voies et des voies réservés sur
certaines sections. Paris fait même figure d'exception en France parmi les
villes qui gardent encore des feux de circulation un peut partout (et qui
pourtant congestionnent la circulation et entraîne beaucoup de bruit et
pollution: la mairie de Paris ne fait rien pour changer ça sans doute à
cause du coût pharaonique que représenterait les acquisitions de terrains
pour aménager les ronds-points; elle préfère fermer des voies à la
circulation auto pour les réserver aux cyclistes, piétons et bus (mais
encore avec des feux, donc les accidents ne baissent pas et pas vraiment
non plus le bruit et la pollution qui sont seulement déplacés en concentrés
ailleurs avec encore plus de congestion). Paris est encore géré comme on le
faisait dans les années 1960-1970 quand la voiture était reine, le
carburant pas cher, et on ne se souciait pas trop d'environnement (et Paris
a toujours été bruyante et très polluée depuis des siècles).

Mais Paris refuse de regarder ce qui se fait dans d'autres grandes agglos
(même Lyon, Marseille, ou d'autres capitales à densité comparable comme
Londres, Bruxelles, Madrid, Rome, Milan) et vit encore dans l'illusion de
la "ville-lumière" des siècles passés (elle se donne juste des excuses avec
quelques "voies vertes" et son réseau cyclable est très mal fichu et pas
protégé du tout, c'est encore la ville des conducteurs de carosses qui
s'engueulent à chaque carrefour entre eux et avec les piétons, en guise de
façon de régler les priorités). Pourtant de nombreux carrefours à Paris
pourraient devenir des giratoires sans nécessiter d'acquisition de terrains

Notez

Re: [OSM-talk-fr] [VélOSM] Rond point et relations routes

> Découper un rond point est malheureusement parfois nécessaire  :
> l'aménageur a fait une bande cyclable en double sens sur une partie seulement 
> du rond point...

C'est un cas particulier, une exception à la règle ?
Il pourrait-être contourné en ajoutant un arc de cercle avec les tags 
appropriés ?

En pratique cet aménagement ne se voit pas encore sur les photos : je suis 
curieux de voir ça.


> Je crois que le problème est plus général avec les routes

Ce n'est pas gênant car JOSM met à jour la relation.

Pour les "giratoires", l'éditeur de relations de JOSM n'affiche plus ça comme 
un giratoire…
On arrive à recouper plein de fois un rond point avec beaucoup de sorties… pour 
rien (le calculateur d'itinéraire sait comment circuler dedans)

Quand le giratoire contient beaucoup de relations ça devient vite l'enfer :
Je vous invite à réparer les lignes de bus d'Annecy.

Un moyen d'éviter ces prises de tête avec les itinéraire serait ne ne pas le 
décrire par les segments de voies, mais par des points clés :
On indiquerait ±précisément les endroits où tourner, et un calculateur 
d'itinéraire ferait le reste.
__
Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-au] Contributions to Road Geometry in Perth, Australia

2020-09-01 Thread Andrew Harvey

Heads up, looks like their team has started to map in Perth, see on OSMCha
-> https://osmcha.org/?aoi=80b50a6d-6bb5-48cb-8ac4-4b2ddd9d5d76

Mostly looks okay to me, and mostly minor tweaks, though I raised a few
questions and issues on changeset comments but also listed most of them
here:

https://www.openstreetmap.org/way/840589945/history was added but the
existing road name and other applicable attributes were not applied. This
same issue happens in quite a few other places too so appears to be
systemic. I've raised some changeset comments but worth including this as
part of the standard practice by your editing team.

https://www.openstreetmap.org/way/842851495/history is that a roundabout? I
can't tell from the Maxar imagery, yet that is the claimed source, how
could you tell from the imagery what this is?

I personally find splitting ways for a traffic island at roundabouts like
in https://www.openstreetmap.org/way/840189281/history a tad to excessive
(would prefer to just tag the node as traffic island and use one way, gives
a much cleaner dataset as the transition between dual and single
carriageways is always messy) but I guess it's not wrong and both styles
are popular in OSM currently. Does the community have a view on this?

Unclear source of the turn restriction in
https://www.openstreetmap.org/changeset/90223764#map=18/-32.04553/115.80953

On Sun, 16 Aug 2020 at 21:28, OSM NextBillion. AI 
wrote:

> Thank you cleary for valuable insights, we would be more cautious while
> mapping in such areas. While Satellite Imagery is our prime resource, we’d
> consider mapillary photos as well wherever available. We do have some
> expert assistance in our team for interpreting satellite imagery and map
> something only if we’re double sure of it’s existence. We will refer to
> mappers history before editing existing data to understand if it was
> created using local expertise and would change only if there is conclusive
> evidence from satellite and mapillary imageries.
>
> We will reach out to local mapping experts through forum and/or changeset
> comments if we require further help.
>
> Thank you all once again for the suggestions, we look forward to working
> with you all. :)
>
>
> On Sun, 16 Aug 2020 at 05:35, cleary  wrote:
>
>>
>> Thanks for the interest in mapping in Australia and thanks for posting
>> your plans on this list.
>>
>> I would add to the caution expressed by others.  I live in an urban
>> location in Australia but I have travelled in other areas within
>> Australia.  It has taken me quite some time to learn to interpret satellite
>> imagery and I still have a lot to learn about this country.  After
>> personally visiting areas and noting what I see, and sometimes taking
>> photographs, I then return home and compare my notes with what I see in the
>> imagery and I am still surprised.  I think it can be quite precarious to
>> map features using just satellite imagery unless you have expert assistance
>> in interpreting the imagery.  For example, a common error by others has
>> been to map lines of cleared vegetation as roads when they are actually
>> fences. Even where an unmapped road exists, it is probably still unmapped
>> because it is a private road and not accessible by the public - many of the
>> roads on rural properties in Australia are private and, if added to the
>> map, need to marked as such. Farmers get annoyed about intruders on their
>> farms especially as biosecurity is a significant concern in parts of
>> Australia.
>>
>> So while I appreciate contributions to the map, I suggest that "armchair"
>> mapping needs to be undertaken with a lot of caution.
>>
>>
>>
>>
>> On Sat, 15 Aug 2020, at 2:17 AM, OSM NextBillion. AI wrote:
>> > Hi all,
>> >
>> >
>> >
>> > We’re a small team based out of Hyderabad, India. We would be doing
>> > minimal edits in Perth and contribute to OSM in the next couple of
>> > weeks, in-line with OSM and Australia specific tagging guidelines [Link
>> > ].
>> >
>> >
>> > Please refer our Wiki
>> >  and Github
>> >  project pages for
>> > more information.
>> >
>> > Looking forward to suggestions, if any ☺
>> >
>> > Thanking you in advance,
>> > Team NextBillion
>> > ___
>> > Talk-au mailing list
>> > Talk-au@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-au
>> >
>>
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org

Re: [OSM-talk-fr] No U-turn vs BRouter

TL;DR: overtaking=no

Le 01/09/2020 à 12:35, Francois Gouget - fgou...@free.fr a écrit :

On Sun, 30 Aug 2020, Francois Gouget wrote:
[...]

Je pense que le no-u-turn était sensé indiquer qu'on ne doit pas faire
demi-tour là où les deux voies se rejoignent. Cela me parait très
superflu.

En fait les restrictions ne sont pas totalement superflues :
https://brouter.de/brouter-web/#map=19/45.78552/-1.15725/standard=-1.156756,45.785759;-1.158315,45.785505=car-eco

Si superflues car fausses (mauvais tag).

Je pensais que BRouter prenait en compte ce genre de connection aux
rond-points. Cela dit je comprends tout à fait que ce ne soit pas le
cas: trop d'exceptions à coder à la main. Et puis le cas où le point de
départ est en sens unique en sortie de rond-point ne doit pas se
produire souvent.

Je ne suis tout de même pas sûr que ces restrictions soient justifiées :
* Doit-on mettre une interdiction de faire demi-tour à chaque fois qu'il
y a une ligne blanche ?

Non, non et non, une ligne blanche c'est overtaking=no (interdiction de
doubler/passer sur l'autre voie).

* Je ne me vois pas faire demi-tour (en fait tourner à gauche) comme ça
en sortie de rond-point. Mais s'il y a une ligne discontinue cela
serait-il vraiment interdit ?

Non, si la ligne est discontinue tu as le droit (enfin là tu es sur une
départementale).

Mais tu ne dois pas le faire (en cas d'accident tu auras tort) car du
fait du giratoire, tu ne peux voir assez les véhicules venant de l'arrière.

Sur Paris c'est interdit

sauf à un carrefour (mais OSM ne connaît cette règle).

* Ni la page du wiki sur les rond-points, ni celle sur les relations
restriction ne parlent de ce cas. La version anglaise de la page sur
les rond-points montre un exemple assez complet mais n'indique pas de
mettre des no-left-turn sur leurs sorties.

https://wiki.openstreetmap.org/w/images/2/2f/Roundabout-tagging.png

Donc il ne semble pas y avoir de règle établie dans un sens ou dans
l'autre.

Du coup que faire ?

overtaking=no s'il y a une ligne continue.

Ce n'est pas spécifique aux ronds-points. A mettre le cas échéant sur
les voies d'accès. Tu peux le préciser sur le wiki si tu veux.

Mon plan serait de :
* Supprimer les no_u_turn sur la voie qui mène à la paire de sens
uniques car elles sont fausses : à partir du moment où il n'y a pas de
ligne blanche on peut faire demi-tour. En l'absence de photo il
faudrait peut-être quand me vérifier qu'il n'y a pas de panneau
interdisant de faire demi-tour.
https://www.openstreetmap.org/relation/7488796

Oui

* Supprimer les restrictions no_u_turn lorsqu'il n'y a qu'une voie qui
mène au rond-point (au lieu d'une paire de sens uniques) car elles
cassent le routage et sont fausses.
https://www.openstreetmap.org/relation/7488797

Oui

* Corriger les autres restrictions incorrectes. Par exemple :
https://www.openstreetmap.org/relation/7347721

Oui, c'est à dire les remplacer par overtaking=no.

* Ne pas mettre de restriction lorsque je crée des rond-points.

Alors certains vont dire que je me répète : le problème figure en
méta-données du changeset :

created_by iD 2.3.2

Car iD incite à ajouter de telles relations.

Et les personnes en toute bonne foi se mettent à décrire (mal) une
interdiction qui est portée non par le giratoire mais par la ligne blanche.

Et tant qu'à corriger tu peux signaler le problème au créateur de la
relation.

Jean-Yvon

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

Re: [OSM-talk-fr] Rond point et relations routes


Tu veux parler de giratoires ? ;-)

Je crois que le problème est plus général avec les routes : on n'arrête
pas de les couper pour des limites de vitesse, stationnement, files...

C'est qu'il manque un niveau d'information : la rue, le giratoire, à
distinguer du segment de route.

Pour la rue on a associatedStreet. Mais pour le rendu on utilise le nom
de chaque segment avec n fois Rue Tartempion sur la carte.

Et le découpage des giratoires est fait en fonction des trajets de bus,
pas des segments (si deux routes se croise et que le bus route, on va
avoir un segment d'un côté et trois de l'autre).

On pourrait ici avoir 4 segments dans une relation round-about.

Ce serait propre et utilisable si les outils le supportaient.

Je crains qu'il vaille mieux s'en tenir à l'existant.

Usuellement je ne découpe que si le reste du trajet de bus les
giratoires sont découpés.

Jean-Yvon

Le 01/09/2020 à 11:24, Yves P. - yves.prat...@gmail.com a écrit :

Bonjour,

Je tombe sur des itinéraires vélos, bus… qui passent par des ronds-points.

Ces derniers sont coupés en petits morceaux pour avoir un bel itinéraire.
Ça part d'une bonne intention (j'ai fait la même chose au début), mais c'est 
ingérable !

S'il vous plait ne serez pas le sécateur quand vous croisez un giratoire.
Merci pour lui et son intégrité 

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



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

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

oui ça remarche ce midi, hier soir l'internet était un enfer à naviguer.
(sauf les sites Google, et le reste était extrèmmeent lent, surtout le DNS
et presque tout ce qui transitait par les gros datacenters d'Amsterdam)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Projet du mois : Près d’un tiers des défibrillateurs ne seraient pas opérationnels en France !

Alors qu’une loi oblige depuis le 1er janvier les établissements recevant du 
public à s’équiper de défibrillateurs automatiques externes, 20 à 30% des 
machines déjà installées en France ne seraient pas en état de marche en raison 
d’un défaut de maintenance.

https://www.capital.fr/economie-politique/pres-dun-tiers-des-defibrillateurs-ne-seraient-pas-operationnels-en-france-1360334

__
Yves



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

Re: [OSM-talk-fr] No U-turn vs BRouter

2020-09-01 Thread Francois Gouget

On Sun, 30 Aug 2020, Francois Gouget wrote:
[...]
> Je pense que le no-u-turn était sensé indiquer qu'on ne doit pas faire
> demi-tour là où les deux voies se rejoignent. Cela me parait très
> superflu.

En fait les restrictions ne sont pas totalement superflues :
https://brouter.de/brouter-web/#map=19/45.78552/-1.15725/standard=-1.156756,45.785759;-1.158315,45.785505=car-eco

Je ne suis tout de même pas sûr que ces restrictions soient justifiées :
* Doit-on mettre une interdiction de faire demi-tour à chaque fois qu'il
y a une ligne blanche ?

* Je ne me vois pas faire demi-tour (en fait tourner à gauche) comme ça
en sortie de rond-point. Mais s'il y a une ligne discontinue cela
serait-il vraiment interdit ?

https://wiki.openstreetmap.org/w/images/2/2f/Roundabout-tagging.png

Donc il ne semble pas y avoir de règle établie dans un sens ou dans
l'autre.

Du coup que faire ?

* Corriger les autres restrictions incorrectes. Par exemple :
https://www.openstreetmap.org/relation/7347721

* Ne pas mettre de restriction lorsque je crée des rond-points.

--
Francois Gouget http://fgouget.free.fr/
If it stinks, it's chemistry. If it moves, it's biology.
If it does not work, it's computer science.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Maß für die Genauigkeit von Eigenbau-GPS-Geräten?

2020-09-01 Thread Manuel Reimer


On 01.09.20 09:56, Stephan Knauss wrote:
Mal zu Fuß dicht an hohen Häuserwänden gehen. Die Hoffnung wäre, dass 
die Empfänger mit mehr Satelliten hier weniger problemen mit Reflektion 
haben. Da dürfte dann vermutlich auch die Antenne eine Rolle spielen.


Teste ich noch. Also das Laufen von "guter Empfang" entlang einer 
Hauswand wieder zu "guter Empfang".


Testhalber hatte ich gerade aber mal WBT-202 (u-blox 5) und NEO M9N 
nebeneinander an meiner Fensterbank und da eine halbe Stunde geloggt.


Der alte Chip driftet extrem weg von der Hauswand. Ich hab eine starke 
"von Hauswand weggerichtete" Abweichung von bis zu 33 Metern.


Der neue Chip hat schon nach recht kurzer Zeit HDOP-Werte von knapp über 
1 erreicht und im Log habe ich nun Abweichungen nicht nur weg von der 
Hauswand sondern auch zum Haus hin. Abweichung rund um die Position an 
der das GPS-Modul gelegen hat: Etwa 5 Meter.


Das große Problem wird der Preis werden. Diese ganzen kleinen Handlichen 
Logger hat man ja problemlos bei eBay für Preise zwischen 30 und 50 Euro 
bekommen, je nachdem ob gebraucht, oder neu.


Ich müsste schauen wo ich den WBT-202 gekauft habe, aber der war neu 
auch teuer.


Wenn du selbst baust wirst du preislich vermutlich deutlich drüber 
liegen, oder?


Kommt stark auf das GPS-Modul an. Und ich hab dann noch ein gekauftes 
Gehäuse drum gebaut und zum Montieren der Teile im Gehäuse ein 
3D-Druck-Teil platziert. Alles in allem kommt man aber auch unter 100 
Euro gut weg.


Zumindest mir ist aber Qualität wichtig. Wenn ich für etwas mehr Geld 
noch bessere Module bekommen hätte, hätte ich auch mehr ausgegeben. Es 
frustet mich einfach nach dem stundenlagen Loggen von Wegen zuhause dann 
"mitteln" zu müssen.



Und dann unterscheiden sich auch noch die Wünsche gewaltig.


Dazu kann ich jetzt schonmal sagen: Ich logge nicht direkt am GPS. Ich 
will unterwegs sowieso am Smartphone direkt mappen. Ich brauche also vor 
allem eine Live-Position auf meinem Smartphone. Geloggt wird dann mit 
OSMTracker und editiert mit Vespucci. Beide Apps können auch 
gleichzeitig laufen und bekommen gleichzeitig Live-Daten. Verbindung 
zwischen GPS und Smartphone steht via Bluetooth. Das Smartphone kann 
also in der Hosentasche bleiben. Das GPS-Modul wird so positioniert das 
der Empfang optimal ist.


Dann musst du unterscheiden wie die Strategie ist um die Messwerte zu 
Glätten. Wenn du schnell Abbiegst, wie genau folgt der Logger dann der 
Spur?


Es wird nix geglättet. Wir reden hier von hochwertigen GPS-Modulen und 
das Signal gebe ich, so wie es kommt, direkt ins Log. Das gibt in meinen 
Tests wunderbar gerade Spuren.


Ich glaube auf den Garmin Geräten hatte die Wahl des Fortbewegungsmodus 
das auch beeinflusst. Im "Kfz" Mode war der Nachlauf in die alte 
Richtung etwas größer.


Geht mit den u-blox-Chips auch. Und noch viel mehr. Ich zeichne aktuell 
mit 1Hz auf aber 10Hz wären möglich.


Klingt nach einem spannenden Projekt. Hast du auf einer Website/Blog 
noch mehr Details? Bilder, Materialliste, etc.. ?


Das wäre dann die nächste Frage: Wo könnte man das dokumentieren. 
Webspace habe ich. Wegen Impressumspflicht habe ich da aber aktuell nur 
rein privates drauf (teilweise hinter Passwortschutz).


Gruß

Manuel

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

[Talk-GB] NCN 231 and NCN 235 Isle of Wight

2020-09-01 Thread Jon Pennycook

Hello.

https://www.openstreetmap.org/relation/2821036 and
https://www.openstreetmap.org/relation/2821037 (claiming to be National
Cycle Network Route 231 and 235) have been listed on OpenStreetMap for some
time. They appear to mostly duplicate Regional Cycle Network route 67 (
https://www.openstreetmap.org/relation/2742) aka "Round The Island" or
"Taste the Wight". 67 is shown on the SusTrans OS Map, but 231 and 235 are
not.
The only NCN signs I have ever seen on the Isle of Wight are for 22 and 23.
I can't find any original sources thst mention either 232 or 235 (they are
mentioned in passing in the Wikipedia article on the NCN). I suspect
someone worked out a proposed route that was never approved, but it got
into OSM anyway.


What should I/we do? E.g.
* Mark 231 and 235 as "Proposed"?
* Delete both relations? How can this be done easily?

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

Re: [OSM-talk-fr] Rond point et relations routes

2020-09-01 Thread Christian Rogel


> Le 1 sept. 2020 à 11:25, Yves P.  a écrit :
> Je tombe sur des itinéraires vélos, bus… qui passent par des ronds-points.
> 
> Ces derniers sont coupés en petits morceaux pour avoir un bel itinéraire.
> Ça part d'une bonne intention (j'ai fait la même chose au début), mais c'est 
> ingérable !
> 
> S'il vous plait ne serez pas le sécateur quand vous croisez un giratoire.
> Merci pour lui et son intégrité 


Déjà mentionné, mais, j’approuve cette piqûre de rappel. Il faut pour agir 
ainsi, soit appartenir à la team 1er degré, soit être certain que le RP est 
positionné correctement. Et surtout au bon diamètre.
Eh, bien, non, ça n’existe qu’au pays de Gaston Lagaffe.
Plusieurs fois, j’ai rétabli l’intégrité et, par respect pour les autres 
contributeurs, laissé dans l’état normal.

Christian R.



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

Re: [talk-cz] Import zastávek veřejné dopravy Jihočeského kraje

2020-09-01 Thread Jan Martinec


Ahoj,

> Dala bych dohromady import. Odkaz na zdroj dat bych dala jen k
> sadě/sadám změn. Přísně vzato by se nejednalo o import, ale o vložení
> dat na základě těch informací, udělala bych tomu jednotlivě ještě ruční
> kontrolu.

to zní jako super nápad, jen mám připomínku k těm názvům:


číslo > ref:JCK - případně otázka, zda vůbec přidávat


Rozhodně ano, chleba to nežere, a ref_name není tesaný do kamene 
(přejmenování ulice etc.).



  * u zastávek typu "Kovářov,Žebrákov,rozc.0.1" vzít část mezi čárkami,
tj. "Žebrákov" jako name, nebo nechat prázdné


Tím vzniknou duplicitní názvy - některé obce mají zastávku "Xyz, rozc. 
0.5" na silnici, a pak ještě "Xyz" v obci, do které ale zajíždí méně 
spojů. (V bizarnějších případech pak více zastávek "...rozc.[X.Y]")

Prostě bych tu zahazoval jen tu část před první čárkou.

Poznámku bych dal do note, proč ne.

K ostatnímu nemám připomínky.

Zdar,
Honza Piškvor Martinec

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

Re: [Talk-it] Edit automatici su nome strade

2020-09-01 Thread Francesco Ansanelli

Ciao,

Dalle mie parti è stata fatta questa modifica:

https://www.openstreetmap.org/changeset/90203182#map=14/44.3327/7.4736

È corretto Giuseppe, ma scritto senza la "i"...
Francesco

Il mar 1 set 2020, 10:15 Andrea Musuruane  ha scritto:

> Ciao,
> vorrei sottoporre alla vostra attenzione che l'utente mcheck sta
> modificando massivamente gli odonimi:
> https://www.openstreetmap.org/user/mcheck/history
>
> Ho commentato un paio di changeset.
>
> Questi mass edit, oltre a non essere concordati e non seguire le
> guidelines, non hanno senso perché senza conoscenza del luogo non si può
> sapere se la strada fosse intitolata a qualcun altro con lo stesso cognome.
>
> Per esempio:
> https://it.wikipedia.org/wiki/Garibaldi_(disambigua)#Persone
> https://it.wikipedia.org/wiki/Mazzini_(disambigua)#Persone
>
> Ciao,
>
> Andrea
>
> ___
> 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

[OSM-talk-fr] Rond point et relations routes

Bonjour,

Je tombe sur des itinéraires vélos, bus… qui passent par des ronds-points.

Ces derniers sont coupés en petits morceaux pour avoir un bel itinéraire.
Ça part d'une bonne intention (j'ai fait la même chose au début), mais c'est 
ingérable !

S'il vous plait ne serez pas le sécateur quand vous croisez un giratoire.
Merci pour lui et son intégrité 

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

[talk-cz] Import zastávek veřejné dopravy Jihočeského kraje

2020-09-01 Thread majkaz

Na https://geoportal.kraj-jihocesky.gov.cz/gs/zastavky-verejne-dopravy/
je už
delší dobu pod licencí CC0 k dispozici seznam všech autobusových a vlakových zastávek
Jihočeského kraje, tj. licence zde by měla být bez problémů. Nejnovější data jsou z
června 2020. Namátkovou kontrolou jsou místa zastávek přesně.
Poskytované informace jsou poloha, plný název, číslo zastávky z katalogu, typ
(autobus/vlak) a stanoviště (příp. poznámka) v případě autobusových nádraží
apod. a informace o tom, zda je aktuálně zastávka obsluhována či nikoli.
Dala bych dohromady import. Odkaz na zdroj dat bych dala jen k sadě/sadám změn.
Přísně vzato by se nejednalo o import, ale o vložení dat na základě těch
informací, udělala bych tomu jednotlivě ještě ruční kontrolu.
Vzala bych jen autobusové zastávky (necelých 6800 bodů) a:
u dat existujících v OSM by se doplnil přesný název zastávky jako ref_name podle toho importu
(https://wiki.openstreetmap.org/wiki/Key:ref_name
)u chybějících dat, zastávek označených
jako "obsluhované" bych je doplnilaNavrhovaný převod dat importní sada > osm
značka "stanoviště_poznámka":
"MHD" - zastávka MHD "autobusové nádraží", týká se Tábora a Jindřichova Hradce
1-99 - autobusové nádraží, číslo zastávky > local_ref
(https://wiki.openstreetmap.org/wiki/Buses#Bus_stops
)
číslo > ref:JCK - případně otázka, zda vůbec přidávat
dlouhé jméno > ref_name
zastávky:
highway=bus_stop
public_transport=platform
místa na autobusových nádražích:
public_transport=platform
+ zkontrolovat, zda existuje amenity=bus_station
K diskusi:
"Neobsluhované" zastávky - hodlám ignorovat, podle mě nelze rozlišit definitivně a
dočasně zrušené zastávky. Alternativně lze připravit sadu "podezřelých" dat z OSM ke
kontrole na místě.
Stanoviště_poznámka,
hodnota "výstup" - jen pro výstup > do poznámky?

hodnota "točna léto" + "občasná" > do poznámky?
Jméno zastávky jako "name" - zda vůbec dělat, případně zda lze jednoduše rozdělit
ref_name do "obecného" názvu zastávky. Příklad hodnot:
"Strakonice,,aut.nádr.", "České Budějovice,,Náměstí Přemysla Otakara II", "Jindřichův
Hradec,,Sv. Barbora", "Kovářov,Žebrákov,rozc.0.1"
Návrhy, jak by to mohlo vypadat, pokud by se skutečně přidávalo:
u autobusových nádraží (je součástí dlouhého jména/má stanoviště) nechávat name prázdné, obvykle používaný název je
"autobusové nádraží"u zastávek typu "České Budějovice,,Náměstí Přemysla Otakara II" vzít část za
",," jako nameu zastávek typu "Kovářov,Žebrákov,rozc.0.1" vzít část mezi čárkami, tj. "Žebrákov"
jako name, nebo nechat prázdnéNápady? Připomínky?
Pokud by někdo chtěl využít i data vlaků, není problém. Jen mám dojem, že
vlakové zastávky máme zmapované podstatně lépe než autobusy.
Majka

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

Re: [OSM-talk-fr] BANO est-il mort? :: les points colorés c'était ma seule utilisation de BANO.

2020-09-01 Thread Jacques Lavignotte




Le 01/09/2020 à 11:01, Christian Quest a écrit :

Je ne sais pas quel usage
tu en faisais, si il correspondait à son but initial et à quel point 
c'est bloquant.


Bonjour Christian,

Mon usage du machin-aux-points-colorés :

Au hasard de mes errances Osmosiennes je profite de la portion de carte 
téléchargé dans JOSM à ce moment là pour monter les points colorés du 
rendu BANO et numéroter la/les rue/s.


Ma demande - très personnelle (?) - le retour du confort du contributeur 
très lambda ( ou même 'oméga' )


J.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [Talk-lt] Kauno naujos gatvės

2020-09-01 Thread Paulius Zaleckas

Jau klojamos, tos kur geltonos, tai jau yra asfaltas ir lyg jau galima
vaziuoti, tiesa pats sujungimas su Europos pr. dar nera baigtas ir ten
gabaliukas zvyro.
Kitos jau irgi isasfaltuotos, bet dar neprijungtos prie kitu gatviu.

On Tue, Sep 1, 2020 at 9:59 AM Tomas Straupis  wrote:
>
> Sveiki
>
>   Gal kauniečiai žino, šitos gatvės jau baigtos, ar dar tik statomos
> (o gal tik planuojamos/projektuojamos)?
>   https://www.openstreetmap.org/#map=17/54.87874/23.90284
>   (dvi gatvės su highway=secondary construction=secondary žymomis)
>
> --
> Tomas
>
> ___
> Talk-lt mailing list
> Talk-lt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lt

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

Re: [OSM-talk-be] Fietsstraatzones in Leuven and a question about zones inside zones

2020-09-01 Thread Jo

I added some A23 here and there around Leuven. It made me realise I don't
have recent Mapillary images for many streets in Leuven to determine where
exactly those school zone30 start and end... Time to go out and cycle to
make more pictures, I guess.

Jo

On Mon, Aug 31, 2020 at 9:52 AM Tim Couwelier 
wrote:

> F4a should remain yes, despite both implying the same speed limit, UNLESS
> the local gov removed the F4a signs due to the 'fietszone' completely
> overlapping with the 'zone 30'.
> Ideally, for the 'zone 30', differentiate between 'normal' with F4a only
> and 'school- zone 30'  (F4a + A23)
>
> If there's living streets within, I'd say the restrictions 'stack': no
> overtaking, 20 km/h.
> There may actually be a slight nuance here - generally in case of possible
> contradiction, the rule applies 'traffic sign takes priority over traffic
> rules'. The speed limits in both fietszone and living_street are traffic
> rules, but this might leave a loophole where 'zone 30' as a sign takes
> priority.
>
> There used to be a loophole where a C43 70km/h would trump the 50km/h
> speed limit in a built up area until the first intersection (extent of the
> validity for the C43) but afaik that's been 'patched' in legislation now.
> This might just be an unforeseen edge case opening another such loophole,
> although I'm not 100% sure on this.
>
>
> Sidenote: I think I agree with not making a seperate sign for this, but
> just giving it a 'zonal' extent. If anything, F4a/b signs existing as such
> is confusing. But then again, so were the original streetsigns as they were
> semi-assumed to be zonal, but the law wasn't overly specific (and didn't
> mention it being zonal). Readability, in database or map format, is far
> better if you speak of 'zonal C43' and 'zonal F111' without having to know
> another number for the same type of thing.
>
> Op zo 30 aug. 2020 om 14:50 schreef Jo :
>
>> Hi,
>>
>> I added the new fietsstraatzones in Leuven to the map. They will be in
>> vigor on September 1st. The legislator didn't create a separate sign, they
>> just decided that it's allowed use F111 on a ZONE sign...
>>
>> I do like to distinguish between the 'real' cycle streets and the
>> 'pretenders', so the ones inside zones and the ones connecting the zones, I
>> guess. I used BE:F111zone as the traffic_sign. I may have done something
>> silly though, as I removed the F4a from the traffic sign tag.
>>
>> If you search for F111 you get all.
>> If you search for F111zone you get all the ones inside the zones.
>> If you search for "F111 -F111zone" in JOSM, you get only the cyclestreets
>> with an actual cycle street sign.
>>
>> If you search for F4a you get all the streets inside the zone30, but the
>> cycle streets are not included in that. How do we want to work with zones
>> within zones? There are also parking zones...
>>
>> Should I have put traffic_sign=BE:F111;BE:F4a;BE:F1a ?
>>
>> Initially I didn't because both are limited to 30km/h, but now I'm
>> thinking I should have.
>>
>> What about the living_street ways? They are also inside the zone30 (and
>> in built-up area), but the traffic rules that apply are BE:F12a. Do we add
>> BE:F12a;BE:F4a;BE:F1a ?
>>
>> Jo
>> ___
>> 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] BANO est-il mort? :: les points colorés c'était ma seule utilisation de BANO.

2020-09-01 Thread Christian Quest


Le 01/09/2020 à 10:26, Jacques Lavignotte a écrit :
Je crois que je n'appréhende pas tous les aspects du orojet BAN0 que 
je ressens comme important, la preuve étant l'effervescence actuelle 
sur le sujet. 



Voici de quoi clarifier...

A la base, l'objectif de BANO est de fournir une base d'adresses la plus 
complète possible sous licence ODbL, car à l'époque (2014) rien de tel 
n'existait.


Pour ça, dès le départ, plusieurs sources sont mixées:

- les adresses déjà présentes dans OSM

- les adresses que les collectivités ont mis en opendata

- les adresses extraites du cadastre par des scripts qui s'appuient sur 
les PDF téléchargeables sur cadastre.gouv.fr


C'est ça le coeur de BANO.


A partir de ça, on a pu établir la liste des noms de rues manquants dans 
OSM ainsi que les adresses manquantes et plusieurs outils périphériques 
ont donc été développés pour accompagner les contributions sur cette 
thématique:


- ceux qui permettent d'avoir un suivi statistique,

- ceux qui permettent de rentrer dans le détail commune par commune sur 
le rapprochement FANTOIR (pour compléter les noms de rues et lieux-dits 
dans OSM)


- ceux qui permettent de préparer des points d'adresses pour les 
intégrer dans OSM,


- et le rendu qui permet de montrer là où il y a des améliorations 
possibles dans OSM (le rouge à dégommer pour déjà compléter les noms de 
rues).



Pour la partie "utilisation" des données, j'ai aussi mis en place 
différents géocodeurs sur bano.addok.xyz ou demo.addok.xyz qui 
permettent d'utiliser les données de BANO.


Ceci s'est dans un esprit "d'escalier"... on créer la base, qui du coup 
permet de détecter certains manques, qui du coup nous pousse à mettre en 
place un outil pour faciliter leur comblement, etc, etc. Au final, cela 
fait tout un engrenage avec de multiples ramifications.


La partie constituant la base a été largement refondue, ainsi que la 
majorité des outils, mais pas encore le rendu. Je ne sais pas quel usage 
tu en faisais, si il correspondait à son but initial et à quel point 
c'est bloquant.


--
Christian Quest - OpenStreetMap France


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

Re: [talk-au] OSM down?

2020-09-01 Thread Mateusz Konieczny via Talk-au


Sounds like reocurence of https://github.com/openstreetmap/operations/issues/426

So yes, something got broken on OSM servers.

Not sure whatever creating issues on openstreetmap/operations is helpful.

Sep 1, 2020, 08:02 by graemefi...@gmail.com:

> Has something crashed?
>
> Was getting a weird error message when trying to save changes earlier, & when 
> I now try to open OSM, I get:
> We're sorry, but something went wrong.
>
> The issue has been logged for investigation. Please try again later.
>
> Technical details for the administrator of this website 
> 
> This website is powered by > Phusion Passenger 
> > ®, the smart 
> application server built by > Phusion> ®. 
>
> OSM problem or mine?
>
> Thanks
>
> Graeme
>

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

Re: [OSM-talk-fr] BANO est-il mort? :: les points colorés c'était ma seule utilisation de BANO.

2020-09-01 Thread Jacques Lavignotte




Le 31/08/2020 à 22:40, Vincent de Château-Thierry a écrit :

Bonjour,


>
> Pour essayer de répondre aux débats, remarques et suggestions :



De: "Yves P." 



> au moins on peut essayer d'avoir un avancement minimum.


Le 28/08/2020 à 19:08, Jacques Lavignotte a écrit :
>
>


Merci aux uns et aux autres, chacun à leur manière de participer au débat.


Je crois que je n'appréhende pas tous les aspects du orojet BAN0 que je 
ressens comme important, la preuve étant l'effervescence actuelle sur le 
sujet.


Me concernant je recentre ma/mes demande/s résumé ici :

> Le 28/08/2020 à 18:44, Vincent de Château-Thierry a écrit :
>
>> Je suppose que tu parle du rendu carto de BANO, les points colorés et
>> les zones rouges à dégommer. Si c'est ça, en effet c'est en panne.
>
> Pour moi comme pour quelques autres (je l'ai déjà dit) les points
> colorés c'était ma seule utilisation de BANO.

Je soutiens l'appel de Jérôme - maintenant inscrit à l'ODJ du prochain 
CA - et souhaite - très égoistement -  son aboutissement prochain au 
moins sur « les points colorés ».


Bonne journée,  Jacques

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

[Talk-it] Edit automatici su nome strade

2020-09-01 Thread Andrea Musuruane

Ciao,
vorrei sottoporre alla vostra attenzione che l'utente mcheck sta
modificando massivamente gli odonimi:
https://www.openstreetmap.org/user/mcheck/history

Ho commentato un paio di changeset.

Questi mass edit, oltre a non essere concordati e non seguire le
guidelines, non hanno senso perché senza conoscenza del luogo non si può
sapere se la strada fosse intitolata a qualcun altro con lo stesso cognome.

Per esempio:
https://it.wikipedia.org/wiki/Garibaldi_(disambigua)#Persone
https://it.wikipedia.org/wiki/Mazzini_(disambigua)#Persone

Ciao,

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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

2020-09-01 Thread Christian Quest


Le 30/08/2020 à 21:20, osm.sanspourr...@spamgourmet.com a écrit :

Le 30/08/2020 à 09:46, Christian Quest - cqu...@openstreetmap.fr a écrit :
Bien souvent dans mes contributions, je remet des POI en surfacique 
alors qu'ils ne sont que ponctuels, la première étape consistant 
souvent à migrer un tag sur un bâtiment entier, mais la seconde, 
quand on le peut, consiste à délimiter plus largement l'emprise de 
tel ou tel POI. Cas typique: les écoles !


J'allais dire ouille.

Car les *points* d'intérêt  ne sont pas des *surfaces* par définition.


Tout dépend de la définition... point d'intérêt ou ponctuel d'intérêt ;)

Attention aussi à la traduction simpliste qu'on a fait de POI, non ?

Réduire un POI à un unique point est quand même une façon minimaliste de 
décrire un lieu rarement ponctuel sur le terrain. J'ai toujours 
considéré qu'un ponctuel c'était bien pour apporter une info minimale, 
mais qu'une surface apporte bien plus d'infos (où commence le POI, où 
s'arrête-t-il, est-il étendu ou pas, etc).



Si par contre tu parles d'objets de nature surfacique telles qu'un 
parking ou un jardin, on est d'accord.


Pour une école je ne sais : tu mets ça sur le landuse ?

Oui, plutôt, quand on peut déterminer l'emprise sinon où mettre le 
ponctuel à part de façon arbitraire ?



Ceci dit souvent quand le PI est surfacique des cartographes (avec 
StreetComplete et autres GoMap) l'ajoutent en ponctuel car leur appli 
ne montre que les PI ponctuels :-(.


Faire un rendu ponctuel peut se comprendre, un parking aura un "P" vers 
le centroid, éventuellement son emprise aura un style surfacique en 
plus. Le nom doit être placé quelque part, il est donc ponctuel lui 
aussi mais déterminé à partir de l'emprise.



La seule solution propre compatible avec les deux mais lourdingue pour 
les petits objets c'est de faire une relation type=boundary avec le 
nœud comme label et le contour en outer comme ici 
.


Bof bof bof... que de complexité pour un usage quasi nul des rôles 
label, d'autant plus que remonter dans les relations est un exercice 
délicat pour les moteurs de rendu.


Dans ce cas précis, je ne trouve pas que la position pour ce label soit 
bien choisie. Elle est trop proche de la route, donc collision avec le 
nom de celle-ci (identique d'ailleurs).



--
Christian Quest - OpenStreetMap France

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

Re: [Talk-de] Maß für die Genauigkeit von Eigenbau-GPS-Geräten?

2020-09-01 Thread Stephan Knauss

On 01.09.2020 09:37, Eifelhunde via Talk-de wrote:
> was auch interessant ist, es gibt für GPS referenzsateliten die fest
> über dem Horizont stehen, mein GPS kann die Empfangen und verarbeiten.
> zeigt so praktisch beide Seiten einer Straße an.

Für meine Anforderungen wäre SBAS/WAAN/EGNOS nicht relevant, da ich 
meine GPS Spuren in einem Land ziehe für die es kein Messnetzwerk mit 
Ionosphärenkorrektur gibt.
Da wäre wichtig, dass der Logger entweder merkt, dass es für den Bereich 
keine Korrektur gibt und er es ignoriert, oder das ganze abschaltbar.

Ich hatte irgendwo mal einen Vergleich gemacht was passiert wenn der 
Logger fälschlicherweise eine Korrektur in einem Gebiet anwendet für die 
es keine Daten gibt. Da kam es zu einem üblen Offset.

Stephan

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

Re: [Talk-de] Maß für die Genauigkeit von Eigenbau-GPS-Geräten?

2020-09-01 Thread Stephan Knauss

Hallo Manuel,

On 31.08.2020 16:30, Manuel Reimer wrote:
> Was würdet ihr noch probieren um Performance zu vergleichen?

Mal zu Fuß dicht an hohen Häuserwänden gehen. Die Hoffnung wäre, dass 
die Empfänger mit mehr Satelliten hier weniger problemen mit Reflektion 
haben. Da dürfte dann vermutlich auch die Antenne eine Rolle spielen.

> Besteht grundsätzlich Interesse am Eigenbau von GPS-Empfängern?
Da meine BT747 Sammlung auch irgendwann nicht mehr funktionieren wird 
und ich auch Bedenken habe mal noch Ersatz für die Akkus zu bekommen, 
besteht schon Grundsätzlich Interesse.

Das große Problem wird der Preis werden. Diese ganzen kleinen Handlichen 
Logger hat man ja problemlos bei eBay für Preise zwischen 30 und 50 Euro 
bekommen, je nachdem ob gebraucht, oder neu.

Wenn du selbst baust wirst du preislich vermutlich deutlich drüber 
liegen, oder?

Und dann unterscheiden sich auch noch die Wünsche gewaltig.

In den letzten Umfragen reichte die Spanne von "wasserdicht", über "mit 
Display" zu "Standard-Batterien", "externe Antenne" und 
Rohdatenaufzeichnung.

Ich vermute auch dass man Anpassungen an der Firmware braucht.
Zu Fuß reicht eine Aufzeichnung mit 1Hz super. Mit dem Auto könnte es 
ruhig etwas mehr sein. Und für fliegende Anwendungen sind wir eher im 
10Hz Bereich.

Dann musst du unterscheiden wie die Strategie ist um die Messwerte zu 
Glätten. Wenn du schnell Abbiegst, wie genau folgt der Logger dann der Spur?

Ich glaube auf den Garmin Geräten hatte die Wahl des Fortbewegungsmodus 
das auch beeinflusst. Im "Kfz" Mode war der Nachlauf in die alte 
Richtung etwas größer.

Klingt nach einem spannenden Projekt. Hast du auf einer Website/Blog 
noch mehr Details? Bilder, Materialliste, etc.. ?

Stephan

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

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)