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

[Andrew Davidson]

On 2/09/2020 7:59 pm, Mateusz Konieczny via Talk-au wrote:


BTW, if he is serial offender why noone ever commented on their talk page?


Because people have been using changeset comments to try an engage with 
the user:


https://resultmaps.neis-one.org/osm-discussion-comments?uid=438078




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

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

[Marc Mongenet]

Bonjour

> Le 02/09/2020 à 10:33, Eric SIBERT via Talk-fr - talk-fr@openstreetmap.org a 
> écrit :
>
> +1 avec les avis précédents: en extra-urbain, l'implicite est devenu 
> tellement incompréhensible qu'il vaut mieux coder explicitement.
> Par défaut c'est 80 km/h sur les chaussées à double sens:
> - sauf sur certaines portions de départementale dans certains départements
Oui, mais je suppose que la source sera alors toujours un panneau.
Mais si le panneau n'est pas répété après une intersection, je suppose
que ça retombe à 80.

> - sauf quand il y a un une voie supplémentaire pour faire un créneau de 
> dépassement
90 km/h dans ce cas.

> - pareil pour les routes pour automobile (panneau C107) à double-sens?
De ce que j'ai compris de l'Article 5 (voir mon autre message), C107
implique le 110 km/h sauf limitation explicite.

> - On peut imaginer une route à double-sens avec un terre-plein temporaire
> pour un carrefour. Ce n'est pas pour autant que le long du terre-plein,
> la limite va passer à 90 km/h.
Effectivement, dans ce cas ça passe carrément à 110 km/h d'après R413-2 !

> Donc l'implicite est difficile à expliquer à l'humain et à l'ordinateur.
> Je ne sais même plus ce qu'il faut mettre pour source:maxspeed dans ces cas 
> là.
Je ne sais pas quelle maxspeed mettre dans certains cas. C'est pour
cette raison que je pense préférable de ne pas essayer de deviner la
limite explicite, mais plutôt indiquer "maxspeed=FR:rural".

Le mer. 2 sept. 2020 à 10:54,  a écrit :
>
> > - On peut imaginer une route à double-sens avec un terre-plein
> >  temporaire pour un carrefour. Ce n'est pas pour autant que le
> > long du terre-plein, la limite va passer à 90 km/h.
>
> En théorie tu as raison. En pratique... Je ne sais si un gars a eu une
> offre spéciale pour réutiliser les anciens panneaux !

A noter que ce cas ne correspond pas à l'exemple avec un terre-plein
temporaire ; c'est le cas à plusieurs voies dans le même sens.
Le panneau 90 est ici superflu, maxspeed=FR:rural + lanes:forward=2
impliquant 90 km/h.

Marc Mongenet

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

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

[Marc Mongenet]

Le mer. 2 sept. 2020 à 01:16, Yannick  a écrit :
> L'implicite est désormais quasi impossible à deviner.
> Je suis donc partisan de mettre systématiquement le maxspeed=* au
> moins c'est clairement renseigné sans équivoque possible.

Oui l'implicite est difficile à maîtriser. Mais le problème que j'ai
rencontré, et je pense qu'il est répandu, c'est que les mappeurs ne
connaissent pas suffisamment bien le code de la route pour expliciter
correctement l'implicite! D'ailleurs, en relisant les textes
réglementaires avant de poster, je me suis rendu compte que je ne suis
pas tout à fait au clair moi-même.

Ainsi, je pense que
https://wiki.openstreetmap.org/wiki/FR:Key:maxspeed#Limitation_de_vitesse
se trompe en écrivant:
> hors agglomération : 80 km/h sur les routes sans séparateur
> de voie, 90 km/h sur les routes avec séparateur
En effet l'article R413-2 donne 110 et pas 90 km/h:
> Hors agglomération, la vitesse des véhicules est limitée à []
> 110 km/ h sur les routes à deux chaussées séparées par
> un terre-plein central ;
Le cas n'est pas théorique, je connais une occurrence près de chez moi:
https://www.google.fr/maps/@46.1980371,6.2917578,3a,75y,342.01h,94.36t/data=!3m6!1e1!3m4!1sifBdoBwUx_iYoXFBxbB-lA!2e0!7i16384!8i8192

Il y a aussi la question des routes à accès réglementé, signalées par
le panneau C107 (le carré bleu avec une auto).
Est-ce qu'une route à accès réglementé dont la chaussée contient une
voie dans chaque sens sans terre-plein central est limitée à 80 ou 110
km/h?
Je pense que c'est 110 km/h par application de l'Article 5 de l'Arrêté
du 24 novembre 1967 relatif à la signalisation des routes et des
autoroutes:
> Ce signal annonce le début d'une section de route autre
> qu'une autoroute, réservée à la circulation automobile,
> sur laquelle les règles de circulation sont les mêmes que
> celles prescrites aux articles R. 412-8, R. 417-10, R. 421-2
> (à l'exception de 9°), R. 421-4 à R. 421-7, R. 432-1, R. 432-3,
> R. 432-5, R. 432-7 et R. 433-4 (1°) du code de la route et sur
> laquelle, sauf indication contraire, la vitesse maximale des
> véhicules est fixée à 110 km / h.
Mais le cas est peut-être théorique, car je ne connais pas de telle
route sans limitation explicite.

Le 02/09/2020 à 07:16, Gad Jo a écrit :
> Préfère source:maxspeed=FR:urban + maxspeed=80 pour définir partout
> où la vitesse est à 80.

Je suppose que tu voulais écrire source:maxspeed=FR:rural, non?

Le 02/09/2020 à 10:34, Frédéric Rodrigo a écrit :
> Quand la vitesse est implicite, il y encore plus générique que mettre
> explicitement la vitesse. Mais plutôt :
> maxspeed=FR:urban

Est-ce que maxspeed=FR:rural seul est OK pour une route rurale?
Ou bien maxspeed=FR:rural + source:maxspeed=FR:rural est meilleur?
Un simple maxspeed=FR:rural me semble déjà implicitement indiquer que
la source est la vitesse implicite, mais bon.

En fait, ce qui m'intéresse beaucoup avec FR:rural, c'est
1. la simplification induite pour les créneaux de dépassement ;
1.1. Au lieu de maxspeed:forward=90 + maxspeed:backward=80 ;
simplement maxspeed=FR:rural ;
2. De ne pas devoir choisir entre 80, 90, et 110, pour les routes à
chaussées séparées ;
2.2. Sur la route visible avec l'URL google que j'ai donné ci-dessus,
je pense que la loi dit 110, mais les automobilistes vont pratiquement
tous à 80.

Marc Mongenet

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

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

[brad]

I'm with Kevin, SteveA, etc,  here.   In the part of the world that I 
live, a map without national forest & BLM boundaries is very 
incomplete.   A useful OSM needs this.   The useful boundary would be 
the actual ownership boundary, not the outer potential ownership 
boundary.   Messy, I know.


On 9/1/20 7:05 AM, Kevin Kenny wrote:
On Tue, Sep 1, 2020 at 12:52 AM Bradley White 
mailto:theangrytom...@gmail.com>> 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


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

[OSRM-talk] OSRM Routing updates

[Steven Hirschorn]

Hi All,

I've noticed that the OSRM routes at routing.openstreetmap.de haven't
updated in 3 weeks (assuming the timestamps at
https://routing.openstreetmap.de/timestamps/ are correct)

Is this gap between updates to be expected? I saw something in the OSM
forum about the updates being every few days?

Thanks,
Steven

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

Re: [OSM-talk] maps/navigation data source

[Mike Thompson]

Ben,

What type of navigation, car, public transport, bicycle, walking...?

What part of the world will you be navigating in?  Some parts of the world
have better OSM data than others.

Another consideration is how well the app makes use of all of the data in
OSM. e.g. turn restrictions, oneway, types of travel allowed...

I use the free, open source, OSMAND app. https://osmand.net/

Mike


On Wed, Sep 2, 2020 at 3:49 PM  wrote:

> Hi,
> Navigation app for my iOS device (Navigator by MapFactor) offers two
> choices regarding maps/navigation data source. These are (i) OpenStreetMaps
> and (ii) TomTom. One can load maps from both sources to app. One seems to
> can use both however not at the same time.
> For decision if it is worth to order TomTom maps for that app I wonder
> which differences between those two data sources should I be aware of
> before deciding if OpenStreetMaps maps will suffice or if I like
> additionally to have a backup by TomTom maps.
>
> Any suggestions?
> Which source of knowledge might help on finding answer to asked question?
>
> -
> FreeMail powered by mail.de - MEHR SICHERHEIT, SERIOSITÄT UND KOMFORT
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] Cooper Country State Forest in Keweenaw County, MI [parcel ownership]

[Kevin Kenny]

On Wed, Sep 2, 2020 at 5:34 PM Doug Peterson <
dougpeter...@dpeters2.dyndns.org> wrote:

> That is made up of two properties. The southern, larger square is owned by
> Thomas & Jane Griffith. The northern, smaller square is owned by the John &
> Jane Griffith. The other square to the west of that, not included, is owned
> by John & Jane Griffith. That is just ownership. That does not say whether
> is any sort of "easement" (possibly the wrong choice of word) that could
> cause it to be included.
>
> This can be referenced from Landgrid.
>
>
> https://landgrid.com/us/mi/keweenaw/allouez#b=none=property=/us/mi/keweenaw/27
>
>
> https://landgrid.com/us/mi/keweenaw/allouez#b=none=property=/us/mi/keweenaw/15
>
>
Since it's showing up there, and it isn't showing up in the DNR Parcels
data set (which shows conservation easements as well as land owned in fee
simple), we have two confirmations that it's indeed private.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Unintentional improvements in OSM data influencing / improving other databases

[Kevin Kenny]

On Wed, Sep 2, 2020 at 2:48 PM Joseph Eisenberg 
wrote:

> But if we are talking about legal parcel boundaries or legal protected
> area boundaries, or administrative limits, then it's not at all possible
> for OpenStreetMap users to resolve these conflicts in our database alone.
>
> What needs to happen is bringing this information back to the local
> government and asking them to correct the data and provide an
> authoritative, public-domain source for everyone to use.
>
> It's no good if OpenStreetMap has a more "accurate" boundary line which
> follows a physical feature like a ridgeline, if the legal definition is
> different. Determining this might require lawyers getting involved.
>
> Now certainly OpenStreetMap data, which can include features like
> ridgelines, waterways, roads and paths, which are often used to determine
> historic land ownership boundaries, can be useful in determining if
> existing databases are accurate and precise. But unless those outside
> databases are corrected, our data will be inaccurate as well, when it comes
> to legal issues like boundaries.
>

You are labouring under a misconception that there is some authoritative
database somewhere in the halls of government. There simply is not.

In the US legal system, the verbal description of a property in a deed
takes absolute precedence over any map, and the witness marks in the field
*are* the boundary. Recovering and refreshing the marks is a big part of
what a land surveyor does.

If there is a dispute over a boundary,  the courts can resolve it. In the
cases we're talking about, the courts will not weigh in because there is no
case or controversy before them.

In no case is _any_ government GIS system in most states[1] of the US an
authoritative reference for a property line, and there is nothing
resembling a Torrens title system. Even in the ten or so states that
maintain a registry of land plans as well as titles, the verbal description
generally takes priority over the map. The registries are more about
identifying parcels, and tracking who owns them (and holds easements,
liens, deeds of trust, and the like) than they are about specifying the
metes and bounds of the parcels.

One reason that my uncle's feud with his neighbour could go on so long was
that the formal description of the property was something like 'SW/4 of
NW/4 of Section XX, Lot YY, Great Lot ZZ, Division 1 of the Minisink Patent
of 1704.  Searching that sort of title is like writing _Roots_!
Fortunately, when my brother and the neighbour decided to bury the hatchet,
a forester with a metal detector was able to recover not only corner
monuments, but the remains of a barbed-wire fence - so there was an obvious
place to strike the line.

Even for public land, there's no single authoritative source.  In New York,
for instance, there was a legal dispute about land ownership between
private landholders and the state that went back to the 1860s that required
a statewide constitutional referendum in 2013 to authorize the settlement.
https://www.wamc.org/post/new-york-settles-adirondack-land-dispute . (Yes,
the place is named 'Township 40'.) When this sort of title dispute can
languish for 150 years, how could there be an authoritative reference?

There are cases where I've left inconsistent boundaries in OSM
intentionally. In at least one of those places, I successfully recovered
monuments at both of the inconsistent corners. That one's beyond my pay
grade and will be an issue for the courts if there's ever a dispute.
(Unlikely, both sides of the line are protected forest land, belonging to
different authorities.)

In typically American-capitalist fashion, in lieu of state registration, we
have a privatized system of title insurance
.

[Notes]

[1] There's limited Torrens title in Colorado, Georgia, Hawaii, Illinois,
Massachusetts, Minnesota, New York, North Carolina, Ohio and Washington.
Several of these states are in the process of abolishing it.

In New York, Torrens title was abolished in 2000, and there have been no
new land title registrations since. Even before then, it was optional,
complex and expensive. (I bought my house in 1993 and got a warranty deed,
not a certificate of registered title.) There are still some landowners
still have a Certificate of Title rather than a deed. There are only a
handful of Torrens properties in most counties. It is most common in
Suffolk County, and there are several in Kings and Rockland counties. It's
now considered rather a blemish; many title insurers won't accept a
certificate of title and need to do an extended search to protect against
claims of fraud against the certified title. It's a mess.

Illinois has abolished its Torrens system entirely, but again, there are
issues surrounding legacy title, so the registry must remain accessible.

Torrens title has been unpopular because it is vulnerable to fraudulent
deeds and has been abused

[OSM-talk] maps/navigation data source

[ben . kimdi]

Hi,
Navigation app for my iOS device (Navigator by MapFactor) offers two choices 
regarding maps/navigation data source. These are (i) OpenStreetMaps and (ii) 
TomTom. One can load maps from both sources to app. One seems to can use both 
however not at the same time.
For decision if it is worth to order TomTom maps for that app I wonder which 
differences between those two data sources should I be aware of before deciding 
if OpenStreetMaps maps will suffice or if I like additionally to have a backup 
by TomTom maps.

Any suggestions?
Which source of knowledge might help on finding answer to asked question?
-
FreeMail powered by mail.de - MEHR SICHERHEIT, SERIOSITÄT UND KOMFORT

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

Re: [Talk-GB] How closely do we map lamp posts?

[Dave F via Talk-GB]

I already answered your last point.
Good to see the give way is against the motor vehicles.

On 02/09/2020 22:37, Lester Caine wrote:

On 02/09/2020 19:00, Dave F via Talk-GB wrote:
I don't know the area. but they look like the existing posts to me. 
Has the cycle path been realigned around them to provide better 
vision splays/ stopping room to motorists?


https://www.google.co.uk/maps/@51.7730673,-1.2396435,3a,56.4y,188.18h,85.12t/data=!3m6!1e1!3m4!1sCSZk4LPVkVJecufviv4kzw!2e0!7i13312!8i6656 

I believe it's something to do with building regs. Existing posts 
have to be one of the last items to be decommissioned, usually by 
newly installed ones. Similar happened on one of the London CS ways, 
where everyone got their knickers in a twist over it.


The fact that a neatly finished cycleway surface now has to be dug up 
so that the electric supply can be moved to a new location and the 
lamp pole moved is just another example of the complete waste of money 
many of these 'improvements' result in? Actually another question is 
just why the kerb to the footpath and the cycleway had to be moved at 
all? It no longer lines up with the next section anyway.





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

Re: [talk-cz] Geoget a rozcestníky OSM

[Tom Ka]

Tak to jsem zvedavej. Pokud by to nekdo zkusil, tak se podelte o
vysledek, pripadne screenshoty :-)

Bye tom.k

st 2. 9. 2020 v 21:56 odesílatel Petr Schönmann  napsal:
>
> Ahoj, narazil jsem na zmínku využití OSM.cz a vrstvy s rozcestníky v programu 
> pro Geocaching - Geoget.
> https://www.facebook.com/programgeoget/posts/10164263397985515
>
> Tak třeba začnou přibývat rozcestníky od geocaching komunity ;)
> ___
> 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-GB] How closely do we map lamp posts?

[Lester Caine]

On 02/09/2020 19:00, Dave F via Talk-GB wrote:
I don't know the area. but they look like the existing posts to me. Has 
the cycle path been realigned around them to provide better vision 
splays/ stopping room to motorists?


https://www.google.co.uk/maps/@51.7730673,-1.2396435,3a,56.4y,188.18h,85.12t/data=!3m6!1e1!3m4!1sCSZk4LPVkVJecufviv4kzw!2e0!7i13312!8i6656 

I believe it's something to do with building regs. Existing posts have 
to be one of the last items to be decommissioned, usually by newly 
installed ones. Similar happened on one of the London CS ways, where 
everyone got their knickers in a twist over it.


The fact that a neatly finished cycleway surface now has to be dug up so 
that the electric supply can be moved to a new location and the lamp 
pole moved is just another example of the complete waste of money many 
of these 'improvements' result in? Actually another question is just why 
the kerb to the footpath and the cycleway had to be moved at all? It no 
longer lines up with the next section anyway.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-us] Cooper Country State Forest in Keweenaw County, MI [parcel ownership]

[Doug Peterson]

That is made up of two properties. The southern, larger square is owned by 
Thomas & Jane Griffith. The northern, smaller square is owned by the John & 
Jane Griffith. The other square to the west of that, not included, is owned by 
John & Jane Griffith. That is just ownership. That does not say whether is any 
sort of "easement" (possibly the wrong choice of word) that could cause it to 
be included.

This can be referenced from Landgrid.

https://landgrid.com/us/mi/keweenaw/allouez#b=none=property=/us/mi/keweenaw/27

https://landgrid.com/us/mi/keweenaw/allouez#b=none=property=/us/mi/keweenaw/15


Thank you,

Doug Peterson

talk-us-requ...@openstreetmap.org wrote ..
> Date: Wed, 2 Sep 2020 19:26:20 +0200
> From: Frederik Ramm 
> To: "talk-us@openstreetmap.org Openstreetmap"
>   
> Subject: [Talk-us] Cooper Country State Forest in Keweenaw County, MI
> Message-ID: <4d1f12fa-41f4-12ab-f0c5-48f532350...@remote.org>
> Content-Type: text/plain; charset=utf-8
>
> Hi,
>
> the DWG has been asked to remove this bit of land
>
> https://www.openstreetmap.org/way/146418027#map=13/47.3306/-88.4441
>
> from the "Cooper Country State Forest" protected area since it has been
> purchased from the state by private individuals in 2006 and "the recent
> plat books show this".
>
> I have been unable to find an online resource to corroborate this claim.
> Googling for "plat books" turned up some very pretty scans of 1800's
> surveyor records ;) Perhaps someone more knowledgeable in the US public
> records landscape can help?
>
> 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: [OSM-talk-fr] test n° 3 depuis Thunderbird

[Georges Dutreix via Talk-fr]

Test n° 2 rejeté par la police (expéditeur incorrect). Je soupçonne un 
petit souci de configuration de FairEmail et non pas de mon fournisseur 
Zaclys, mais je ne vois pas trop quoi.
Je tenterai donc de ne répondre que depuis mon ordinateur... pour voir 
si ça continue. Si jamais vous recevez encore mes messages en Spam, 
dites-le moi en direct.


Merci encore pour les réponses. Bonne soirée.


Le 02/09/2020 à 22:07, osm.sanspourr...@spamgourmet.com a écrit :
Pareil ici : 1 et 3 reçus, pas 2 qui n'est pas en pourriel, ni côté 
serveur ni côté client.


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

Re: [OSM-talk-fr] Test n°1 compte zaclys

[Jacques Lavignotte]

Pas reçu le 3.


Le 02/09/2020 à 21:48, Georges Dutreix via Talk-fr a écrit :

Bonjour à tous,



--
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: [OSM-talk-fr] test n° 3 depuis Thunderbird

[osm . sanspourriel]

Le 02/09/2020 à 21:58, Florian_G - forums+...@floriang.eu a écrit :


Reçu dans ma boite de réception.

Je n'ai pas encore reçu le numéro 2.

++


Pareil ici : 1 et 3 reçus, pas 2 qui n'est pas en pourriel, ni côté
serveur ni côté client.

Je suppose que le message 2 a été expédié avant le 3 ;-)

Jean-Yvon


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

Re: [Talk-us] Cooper Country State Forest in Keweenaw County, MI

[Karson Sommer]

https://mgis.coleman-engineering.com/web/ shows the parcel in question
being privately owned.

On Wed, Sep 2, 2020, 12:27 PM Frederik Ramm  wrote:

> Hi,
>
> the DWG has been asked to remove this bit of land
>
> https://www.openstreetmap.org/way/146418027#map=13/47.3306/-88.4441
>
> from the "Cooper Country State Forest" protected area since it has been
> purchased from the state by private individuals in 2006 and "the recent
> plat books show this".
>
> I have been unable to find an online resource to corroborate this claim.
> Googling for "plat books" turned up some very pretty scans of 1800's
> surveyor records ;) Perhaps someone more knowledgeable in the US public
> records landscape can help?
>
> 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
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] test n° 3 depuis Thunderbird

[Denis Helfer]

Le 02/09/2020 à 21:54, Georges Dutreix via Talk-fr a écrit :

Dernier test depuis mon ordinateur.
Merci de me signaler si vous avez eu ce mail en indésirable. Sinon 
vous pouvez le jeter :-)


C'est fini, je ne vous embête plus.

Merci beaucoup.
Georges


Eagle has landing (1)

1. https://www.fai.org/news/apollo-11-eagle-has-landed

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

Re: [OSM-talk-fr] test n° 3 depuis Thunderbird

[Florian_G]

Re,

Le 02/09/2020 à 21:54, Georges Dutreix via Talk-fr a écrit :
> Dernier test depuis mon ordinateur.
> Merci de me signaler si vous avez eu ce mail en indésirable. Sinon
> vous pouvez le jeter :-)
>
> C'est fini, je ne vous embête plus.
>
> Merci beaucoup.
> Georges

Reçu dans ma boite de réception.

Je n'ai pas encore reçu le numéro 2.

++

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

Re: [OSM-talk-fr] Test n°1 compte zaclys

[Florian_G]

Hello,

Le 02/09/2020 à 21:48, Georges Dutreix via Talk-fr a écrit :
> Mail envoyé depuis FairEmail en changeant l'expéditeur.
>
> Merci beaucoup de me dire si vous avez ce message en indésirable.

Reçu dans ma boite de réception.

++

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

[talk-cz] Geoget a rozcestníky OSM

[Petr Schönmann]

Ahoj, narazil jsem na zmínku využití OSM.cz a vrstvy s rozcestníky v
programu pro Geocaching - Geoget.
https://www.facebook.com/programgeoget/posts/10164263397985515

Tak třeba začnou přibývat rozcestníky od geocaching komunity ;)
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[OSM-talk-fr] test n° 3 depuis Thunderbird

[Georges Dutreix via Talk-fr]

Dernier test depuis mon ordinateur.
Merci de me signaler si vous avez eu ce mail en indésirable. Sinon vous 
pouvez le jeter :-)


C'est fini, je ne vous embête plus.

Merci beaucoup.
Georges
___
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?

[Markus via Talk-de]

Hi Manuel,

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

oder in GitHub
und natürlich im OSM-Wiki :-)

Gruss, Markus


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

Re: [OSM-talk-fr] Test n°1 compte zaclys

[Denis Helfer]

Le 02/09/2020 à 21:48, Georges Dutreix via Talk-fr a écrit :

Bonjour à tous,

Je vais être un peu hors sujet et vous prie de me pardonner.
Plusieurs d'entre vous m'ont signalé que mes mails arrivaient en 
indésirables. Avant d'accuser Zaclys, je voudrais faire quelques 
tests. Trois tests dont celui ci est le premier.

Mail envoyé depuis FairEmail en changeant l'expéditeur.

Merci beaucoup de me dire si vous avez ce message en indésirable.

Georges


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

[OSM-talk-fr] Test n°1 compte zaclys

[Georges Dutreix via Talk-fr]

Bonjour à tous,

Je vais être un peu hors sujet et vous prie de me pardonner.
Plusieurs d'entre vous m'ont signalé que mes mails arrivaient en indésirables. 
Avant d'accuser Zaclys, je voudrais faire quelques tests. Trois tests dont 
celui ci est le premier.
Mail envoyé depuis FairEmail en changeant l'expéditeur.

Merci beaucoup de me dire si vous avez ce message en indésirable.

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

Re: [Talk-us] Cooper Country State Forest in Keweenaw County, MI

[Frederik Ramm]

Correct, sorry, my mistake!

On 9/2/20 20:02, Kerry Irons wrote:
> It's Copper Country, not Cooper Country. 
> 
> Kerry Irons 
> 
> On Wed, Sep 2, 2020, 1:55 PM Kevin Kenny  > wrote:
> 
> 
> 
> On Wed, Sep 2, 2020 at 1:47 PM Joseph Eisenberg
> mailto:joseph.eisenb...@gmail.com>> wrote:
> 
> My goodness, look at that monstrosity:
> 
> https://www.openstreetmap.org/relation/1976405#map=8/46.459/-87.627
> 
> How can we claim that all of these patches of state-owned land
> constitute a single OpenStreetMap feature?
> 
> 
> Because they share a name, share a management plan, are managed as a
> whole, are signed alike, enjoy the same protection status, and are
> popularly thought of as a unit.
> 
> The US has some untidy and diffuse features. Some of those untidy
> and diffuse features are important to those who live around them,
> earn their livings by them, or recreate in them. Don't demand that
> we refrain from mapping them because they fail to conform with your
> mental model of the world as it ought to be. It comes across as
> saying, "My model is fine, fix your country!" I can't fix it, in any
> reasonable timeframe at least. I'm constrained to mapping the
> country I have.
> 
> -- 
> 73 de ke9tv/2, Kevin
> ___
> 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
> 

-- 
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-us] Unintentional improvements in OSM data influencing / improving other databases

[Joseph Eisenberg]

RE: "Many government and agency data sources are in conflict with each
other over the same information; OSM can serve to provide "resolved"
versions that are confirmed with ground observation where required."

Similar thoughts have been expressed previously in this thread.

But if we are talking about legal parcel boundaries or legal protected area
boundaries, or administrative limits, then it's not at all possible for
OpenStreetMap users to resolve these conflicts in our database alone.

What needs to happen is bringing this information back to the local
government and asking them to correct the data and provide an
authoritative, public-domain source for everyone to use.

It's no good if OpenStreetMap has a more "accurate" boundary line which
follows a physical feature like a ridgeline, if the legal definition is
different. Determining this might require lawyers getting involved.

Now certainly OpenStreetMap data, which can include features like
ridgelines, waterways, roads and paths, which are often used to determine
historic land ownership boundaries, can be useful in determining if
existing databases are accurate and precise. But unless those outside
databases are corrected, our data will be inaccurate as well, when it comes
to legal issues like boundaries.

- Joseph Eisenberg

On Wed, Sep 2, 2020 at 11:39 AM Bradley White 
wrote:

> I echo this sentiment exactly as having taken place in California and in
>> my experiences with OSM.  This is most certainly a longer-term endeavor
>> (over several, even many years), but improvements in alignments between
>> data components which have been entered into OSM from my County GIS,
>> GreenInfo.org's publishing its "CPAD" (California Protected Area Database,
>> published semi-annually, see our wiki) and other sources HAVE INDEED
>> resulted in data improvements:  OSM influences CPAD, resulting in data
>> improvements, CPAD influenced County GIS data, resulting in data
>> improvements, later versions of these (County GIS and CPAD) data influenced
>> OSM all over again, resulting in data improvements...and upward, upward and
>> upward the spiral of more accurate, better-aligning data goes:  both
>> private and public.  OSM gets the results, so do others.  Win-win.  Taking
>> OSM out of the equation by asserting "these data don't belong in OSM" stops
>> this improvement pipeline (wholly unintentional on my part, but certainly
>> noticed) in its tracks.  (Yes, some data belong in OSM, some don't).
>
>
> I'm in strong agreement here. OSM provides a unique platform to synthesize
> multiple data sources in combination with field observation to produce
> something potentially better than any of these single sources are on their
> own. Trying to produce an accurate and detailed map of the entire US
> strictly off of field observation and satellite imagery is simply
> infesible, especially in remote, unpopulated areas. Many government and
> agency data sources are in conflict with each other over the same
> information; OSM can serve to provide "resolved" versions that are
> confirmed with ground observation where required.
>
> I agree that we shouldn't be importing parcel data wholesale, as-is. But,
> if real-life accuracy is important, the fact that much of the information
> we are trying to add in OSM (protected areas, land use, access
> restrictions) is differentiated along parcel boundaries is simply
> unavoidable to me. If this information is in the public domain and
> generally corroborates what is on the ground, so long as the data is worked
> through manually to confirm accuracy, I don't see the problem with using
> parcel information as a piece of the "puzzle" in producing an accurate and
> informative map.
> ___
> 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] Unintentional improvements in OSM data influencing / improving other databases

[Bradley White]

>
> I echo this sentiment exactly as having taken place in California and in
> my experiences with OSM.  This is most certainly a longer-term endeavor
> (over several, even many years), but improvements in alignments between
> data components which have been entered into OSM from my County GIS,
> GreenInfo.org's publishing its "CPAD" (California Protected Area Database,
> published semi-annually, see our wiki) and other sources HAVE INDEED
> resulted in data improvements:  OSM influences CPAD, resulting in data
> improvements, CPAD influenced County GIS data, resulting in data
> improvements, later versions of these (County GIS and CPAD) data influenced
> OSM all over again, resulting in data improvements...and upward, upward and
> upward the spiral of more accurate, better-aligning data goes:  both
> private and public.  OSM gets the results, so do others.  Win-win.  Taking
> OSM out of the equation by asserting "these data don't belong in OSM" stops
> this improvement pipeline (wholly unintentional on my part, but certainly
> noticed) in its tracks.  (Yes, some data belong in OSM, some don't).


I'm in strong agreement here. OSM provides a unique platform to synthesize
multiple data sources in combination with field observation to produce
something potentially better than any of these single sources are on their
own. Trying to produce an accurate and detailed map of the entire US
strictly off of field observation and satellite imagery is simply
infesible, especially in remote, unpopulated areas. Many government and
agency data sources are in conflict with each other over the same
information; OSM can serve to provide "resolved" versions that are
confirmed with ground observation where required.

I agree that we shouldn't be importing parcel data wholesale, as-is. But,
if real-life accuracy is important, the fact that much of the information
we are trying to add in OSM (protected areas, land use, access
restrictions) is differentiated along parcel boundaries is simply
unavoidable to me. If this information is in the public domain and
generally corroborates what is on the ground, so long as the data is worked
through manually to confirm accuracy, I don't see the problem with using
parcel information as a piece of the "puzzle" in producing an accurate and
informative map.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Gad.Jo]

Dans un monde parfait mettre uniquement les arrêts serait nickel mais 
cela prive les usagers du tracé.


Dans l'agglo où je vie à part des pdf inexploitable sur un smartphone il 
n'y a aucun plan du réseau. En sus la majorité des plans pdf ne sont pas 
orienté dans le sens nord sud. Cela rend complexe la compréhension de 
leur plan.


Peut être que dans les années à venir seul les arrêts seront suffisant + 
les nœuds où passe la ligne pour lever toute ambiguïté quand le bus 
emprunte non pas la route la plus logique mais celle décidé par la régie 
de transport...


Le 02/09/2020 à 18:49, leni a écrit :



Le 01/09/2020 à 18:23, Gad Jo a écrit :
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.


Il y a les pour et les contre les découpages des giratoires, je ne 
suis pas sûr que l'on arrive à un consensus.


Il y a quelque temps, j'avais fait une analyse des giratoires du 
département où j'habite et j'avais constaté que 16% étaient découpés 
(pas uniquement pour les bus) et qu'un tiers des giratoires découpés 
et traversés par des lignes de bus avaient les relations routes en 
erreur. E cela empirait avec le temps.


Maintenant, si je crée une ligne qui n'a pas encore de relation route, 
je ne met que les arrêts dans l'ordre.


cordialement

leni



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

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

[Yves P.]

> Il y a les pour et les contre les découpages des giratoires, je ne suis pas 
> sûr que l'on arrive à un consensus.
> 

Quel est l'intérêt de découper un giratoire ?

Il y a un cas particulier cité sur la liste vélosm qui "nécessite" un découpage.
Ça reste l'exception, donc (à vu de nez) 99% des giratoires ne devraient pas 
être découpés.

Et encore, si on indique que tout le giratoire à une bande cyclable (alors que 
c'est uniquement une section) les logiciels de routage pour vélo devraient 
fonctionner quand même.
C'est juste le rendu qui poserait problème (comme Waymarked Trails actuellement 
qui colorie tout le rond-point).


> un tiers des giratoires découpés et traversés par des lignes de bus avaient 
> les relations routes en erreur. Et cela empirait avec le temps.
> 
Les relations de lignes de bus étaient déjà bien cassées :(


> Maintenant, si je crée une ligne qui n'a pas encore de relation route, je ne 
> met que les arrêts dans l'ordre.
> 
C'est encore plus radical que ce que je proposais :D
Mais au moins, ça évite les prises de tête.

Par contre, il n'y a plus de rendu du trajet exacte, mais en a t'on vraiment 
besoin pour les bus ??

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

Re: [OSM-talk-fr] Attribution eaupotable.info

[Philippe Verdy]

S'ils ne garantissent rien eux-mêmes, le minimum qu'ils puissent faire
c'est tracer et identifier leurs sources pour savoir d'où ca vient et
comment corriger. S'ils ne le font pas, c'est leur responsabilité directe,
ils peuvent mettre n'importe quoi, n'importe comment, juste pour "faire du
chiffre" et faire croire qu'ils sont une ressource utile (voire
indispensable) ayant une autorité quelconque (par exemple pour utiliser
cela et obtenir des subventions indues même s'ils n'ont aucune expertise ni
aucun processus qualité).

Il vaut mieux une petite source incomplète mais fiable qui peut ensuite
coopérer et échanger avec d'autres petites sources capables de se faire
confiance entre elles et s'accorder du crédit (et sinon ayant des moyens de
contact, un "guichet" d'échange et un système de suivi (ne serait-ce qu'un
dépot GitHub ou similaire, ou une simple feuille de calcul, un forum en
ligne avec archives et un peu de classement possible).

Là ce site me semble totalement fermé et comme n plus il ignore le
minimum légal, ça pose des questions sur son sérieux.

Le mer. 2 sept. 2020 à 16:57, European Water Project <
europeanwaterproj...@gmail.com> a écrit :

> Salut Vincent,
>
> Je reste dubitatif sur le site en lui même qui se nomme eaupotable et
> qui en bas de page signale " Warning: We are unable to guarantee the
> drinkability of the water. Most springs listed are known to be safe, but
> few are regularly checked. "
>
> > Je trouve qu'ils ont raison de signaler qu'ils ne peuvent en aucun
> cas garantir la qualité de l'eau de chaque fontaine.  Notre "disclaimer" va
> pas mal dans le même sens.
>
> A bientôt,
>
> Stuart
>
>
>
> On Wed, 2 Sep 2020 at 09:24, Vincent Bergeot  wrote:
>
>> Le 19/07/2018 à 08:44, Vincent Bergeot a écrit :
>> > Le 11/07/2018 à 09:37, Vincent Bergeot a écrit :
>> >> Le 11/07/2018 à 09:12, Johnparis a écrit :
>> >>> https://eaupotable.info/en/contact/
>> >>
>> >> merci, je leur signale :)
>> >
>> > pour suivi, aucune réponse
>>
>> interpellé sur twitter
>> (https://twitter.com/spoutnik/status/1301014314736742400, ben oui 2 ans,
>> comme quoi les archives publiques c'est bien !!!) j'ai de nouveau
>> utilisé la page contact pour dire que
>> (https://eaupotable.info/en/fr-france) semblait en accord avec
>> https://www.openstreetmap.org/copyright.
>>
>> Je reste dubitatif sur le site en lui même qui se nomme eaupotable et
>> qui en bas de page signale " Warning: We are unable to guarantee the
>> drinkability of the water. Most springs listed are known to be safe, but
>> few are regularly checked. "
>>
>> Et coté données, non utilisable (du moins je n'ai trouvé aucune licence)
>> et la création de nouveau point se fait en utilisant google
>> (https://eaupotable.info/en/create) ce qui doit d'autant plus
>> restreindre une éventuelle licence.
>>
>> pour suivi, puisque qu'un tweet est apparu :)
>>
>>
>> --
>> Vincent Bergeot
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-cz] Import cyklotras a přidružených objektů

[Tom Ka]

Zdravim, s Nadaci Partnerstvi jsme v minulosti byli v kontaktu a o
cyklotrasach jsme i mluvili. Nejste z Brna? Prvni seznameni by asi
bylo nejjednodussi osobne si sednout a probrat co a jak.

Hezky den
tom.k

st 2. 9. 2020 v 16:58 odesílatel Ondra Takács
 napsal:
>
> Zdravím,
>
> jmenuji se Ondra Takács a jsem zaměstnanec Nadace Partnerství. Jedním z 
> našich projektů jsou cyklistické trasy, kde jsme do teď používali Google mapu 
> a mapy.cz a rádi bychom přešli na OSM. V rámci tohoto přechodu bychom chtěli 
> do OSM importovat data, která bychom pak využívali na našich webových 
> stránkách.
>
> Toto je moje první zkušenost s OSM a rád bych se dozvěděl, jestli tato data 
> do OSM importovat můžeme. Taky bych se rád více seznámil s tím, jaké jsou v 
> české OSM komunitě zvyklosti v provádění rozsáhlejšího importu dat.
>
> Nyní stručně popíšu, jaká data chceme importovat:
>
> cyklotrasy, jejich lokaci, název, popis a fotku,
> objekty jako restaurace, hotely, kampy, turistické cíle, u kterých bychom 
> chtěli evidovat:
>
> klasická metadata jako popis, kontaktní údaje, otevírací dobu, odkaz na web, 
> fotky,
> hodnocení tohoto objektu, kdo a kdy to hodnotil, počet hvězdiček 1-5, slovní 
> hodnocení.
>
> Potřeboval bych vědět, jestli by bylo možné taková data do OSM importovat. 
> Které z těchto údajů je vhodné ukládat do OSM a které bychom měli evidovat ve 
> vlastní databázi?
>
> Pro praktickou představu, k čemu to bude sloužit, tady dávám odkazy na naše 
> staré webové stránky, kde teď používáme jiné mapy:
>
> https://www.cyklistevitani.cz/uvod.aspx
> https://www.stezky.cz/mapa-stezek
>
> Děkuji za odpověď
> Ondra Takács
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

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

Re: [Talk-us] Cooper Country State Forest in Keweenaw County, MI

[Kerry Irons]

It's Copper Country, not Cooper Country.

Kerry Irons

On Wed, Sep 2, 2020, 1:55 PM Kevin Kenny  wrote:

>
>
> On Wed, Sep 2, 2020 at 1:47 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> My goodness, look at that monstrosity:
>>
>> https://www.openstreetmap.org/relation/1976405#map=8/46.459/-87.627
>>
>> How can we claim that all of these patches of state-owned land constitute
>> a single OpenStreetMap feature?
>>
>
> Because they share a name, share a management plan, are managed as a
> whole, are signed alike, enjoy the same protection status, and are
> popularly thought of as a unit.
>
> The US has some untidy and diffuse features. Some of those untidy and
> diffuse features are important to those who live around them, earn their
> livings by them, or recreate in them. Don't demand that we refrain from
> mapping them because they fail to conform with your mental model of the
> world as it ought to be. It comes across as saying, "My model is fine, fix
> your country!" I can't fix it, in any reasonable timeframe at least. I'm
> constrained to mapping the country I have.
>
> --
> 73 de ke9tv/2, Kevin
> ___
> 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-GB] How closely do we map lamp posts?

[Dave F via Talk-GB]

I don't know the area. but they look like the existing posts to me. Has 
the cycle path been realigned around them to provide better vision 
splays/ stopping room to motorists?


https://www.google.co.uk/maps/@51.7730673,-1.2396435,3a,56.4y,188.18h,85.12t/data=!3m6!1e1!3m4!1sCSZk4LPVkVJecufviv4kzw!2e0!7i13312!8i6656

I believe it's something to do with building regs. Existing posts have 
to be one of the last items to be decommissioned, usually by newly 
installed ones. Similar happened on one of the London CS ways, where 
everyone got their knickers in a twist over it.


DaveF

On 02/09/2020 18:27, Lester Caine wrote:

https://www.bbc.co.uk/news/uk-england-oxfordshire-53999106
One does wonder about the competence of builders at times?




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

Re: [Talk-us] Cooper Country State Forest in Keweenaw County, MI

[Kevin Kenny]

On Wed, Sep 2, 2020 at 1:47 PM Joseph Eisenberg 
wrote:

> My goodness, look at that monstrosity:
>
> https://www.openstreetmap.org/relation/1976405#map=8/46.459/-87.627
>
> How can we claim that all of these patches of state-owned land constitute
> a single OpenStreetMap feature?
>

Because they share a name, share a management plan, are managed as a whole,
are signed alike, enjoy the same protection status, and are popularly
thought of as a unit.

The US has some untidy and diffuse features. Some of those untidy and
diffuse features are important to those who live around them, earn their
livings by them, or recreate in them. Don't demand that we refrain from
mapping them because they fail to conform with your mental model of the
world as it ought to be. It comes across as saying, "My model is fine, fix
your country!" I can't fix it, in any reasonable timeframe at least. I'm
constrained to mapping the country I have.

-- 
73 de ke9tv/2, Kevin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Cooper Country State Forest in Keweenaw County, MI

[Joseph Eisenberg]

My goodness, look at that monstrosity:

https://www.openstreetmap.org/relation/1976405#map=8/46.459/-87.627

How can we claim that all of these patches of state-owned land constitute a
single OpenStreetMap feature?

-- Joseph Eisenberg

On Wed, Sep 2, 2020 at 10:27 AM Frederik Ramm  wrote:

> Hi,
>
> the DWG has been asked to remove this bit of land
>
> https://www.openstreetmap.org/way/146418027#map=13/47.3306/-88.4441
>
> from the "Cooper Country State Forest" protected area since it has been
> purchased from the state by private individuals in 2006 and "the recent
> plat books show this".
>
> I have been unable to find an online resource to corroborate this claim.
> Googling for "plat books" turned up some very pretty scans of 1800's
> surveyor records ;) Perhaps someone more knowledgeable in the US public
> records landscape can help?
>
> 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
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-GB] How closely do we map lamp posts?

[Lester Caine]

https://www.bbc.co.uk/news/uk-england-oxfordshire-53999106
One does wonder about the competence of builders at times?

--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-us] Talk-us Digest, Vol 153, Issue 22 OSM-US local chapter application (Joost Schouppe [OSMF secretary])

[Maggie Cawley]

>
> Hi All,



> Community consultation for the OpenStreetMap US application to become a local
> chapter of OSMF  [OSMF secretary])>ends on September 5. It would be great to hear from
> more community members, so if you have time and interest please post to the
> wiki, the talk-us list or the osfm mailing list!


Thanks!
Maggie

> --
>
> Message: 1
> Date: Fri, 21 Aug 2020 11:07:01 +0200
> From: "Joost Schouppe [OSMF secretary]" 
> To: talk-us@openstreetmap.org
> Subject: [Talk-us] OSM-US local chapter application
> Message-ID:
> <
> cah1mrign0xhbh-ccfr0gvd4kkyd_ewfp8symusvuw0_4xqi...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
>
> You may be aware that *OpenStreetMap US, Inc.* has applied to become an
> official Local Chapter of the OpenStreetMap Foundation. As part of the
> application process, we would like to ask you, *the local mapping
> community*
> how you feel about this. Do you support this application? Do you have any
> questions, comments or concerns?
>
>
> You can find all the information about this Local Chapter application on
> the OSMF website:
>
> https://wiki.osmfoundation.org/wiki/Local_Chapters/Applications/United_States
>
>
> We will close this round of discussion two weeks from now (Sept 5th 2020).
> You can reply to this thread, send a message to board (at)
> osmfoundation.org,
> or use the wiki talk page here
>
> https://wiki.openstreetmap.org/wiki/Talk:Foundation/Local_Chapters/Applications/United_States
> I am looking forward to hearing your responses.
>
> We will also share this message on Slack and the forum.
>
>
> Thank you to the OpenStreetMap US team for this submission.
>
>
> Best regards,
>
> Joost Schouppe
> *Secretary*
> *OpenStreetMap Foundation*
>
> Name & Registered Office:
>
> *OpenStreetMap Foundation*
> *St John’s Innovation Centre*
> *Cowley Road*
> *Cambridge*
> *CB4 0WS*
> *United Kingdom*
>
> *A company limited by guarantee, registered in England and
> WalesRegistration No. 05912761*
>
> Joost Schouppe
> *Secretary*
> *OpenStreetMap Foundation*
>
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstreetmap.org/pipermail/talk-us/attachments/20200821/1227d68a/attachment-0001.htm
> >
>
> -
> 
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Cooper Country State Forest in Keweenaw County, MI

[Frederik Ramm]

Hi,

the DWG has been asked to remove this bit of land

https://www.openstreetmap.org/way/146418027#map=13/47.3306/-88.4441

from the "Cooper Country State Forest" protected area since it has been
purchased from the state by private individuals in 2006 and "the recent
plat books show this".

I have been unable to find an online resource to corroborate this claim.
Googling for "plat books" turned up some very pretty scans of 1800's
surveyor records ;) Perhaps someone more knowledgeable in the US public
records landscape can help?

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: [OSM-talk-fr] Rond point et relations routes

[leni]

Le 01/09/2020 à 18:23, Gad Jo a écrit :
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.


Il y a les pour et les contre les découpages des giratoires, je ne suis 
pas sûr que l'on arrive à un consensus.


Il y a quelque temps, j'avais fait une analyse des giratoires du 
département où j'habite et j'avais constaté que 16% étaient découpés 
(pas uniquement pour les bus) et qu'un tiers des giratoires découpés et 
traversés par des lignes de bus avaient les relations routes en erreur. 
E cela empirait avec le temps.


Maintenant, si je crée une ligne qui n'a pas encore de relation route, 
je ne met que les arrêts dans l'ordre.


cordialement

leni


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

[Talk-us] Unintentional improvements in OSM data influencing / improving other databases

[stevea]

On September 1, 2020 at 8:07:46 AM PDT, Kevin Kenny  
wrote:
> 
> 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.

Starting a new thread.

I echo this sentiment exactly as having taken place in California and in my 
experiences with OSM.  This is most certainly a longer-term endeavor (over 
several, even many years), but improvements in alignments between data 
components which have been entered into OSM from my County GIS, GreenInfo.org's 
publishing its "CPAD" (California Protected Area Database, published 
semi-annually, see our wiki) and other sources HAVE INDEED resulted in data 
improvements:  OSM influences CPAD, resulting in data improvements, CPAD 
influenced County GIS data, resulting in data improvements, later versions of 
these (County GIS and CPAD) data influenced OSM all over again, resulting in 
data improvements...and upward, upward and upward the spiral of more accurate, 
better-aligning data goes:  both private and public.  OSM gets the results, so 
do others.  Win-win.  Taking OSM out of the equation by asserting "these data 
don't belong in OSM" stops this improvement pipeline (wholly unintentional on 
my part, but certainly noticed) in its tracks.  (Yes, some data belong in OSM, 
some don't).

This is a seldom-talked about real benefit OSM offers to both non-profit based 
data aggregators (like GreenInfo and their CPAD) and public ones (like County 
GIS departments).  Yes, a relatively high-degree of accuracy and careful 
mapping, skilled volunteers in OSM (who likely don't have the credentials of 
professional surveyors, but who are aware of basics like monument markers, 
"metes and bounds" in deeds and the like) ARE required.  So, even volunteer 
"citizen mappers" can go a long distance at improving data, simply by doing 
solid mapping in OSM.  And by remaining a database of high quality and careful 
curation, OSM earns the respect of other GIS professionals (public and private) 
who (over the longer-term) find the puzzle-pieces fitting together better.  The 
examples are numerous, thank you Kevin for providing several.

OSM will likely never become "authoritative" in the sense a cadastral database 
does for tax or land survey purposes, but as we keep our quality high, keep our 
mapping careful and pay attention to things like survey markers (we do), other 
mapping professionals will continue to look to us as "worthy enough" to include 
as a layer on their systems, for example.  OSM does not have the goal of being 
so "authoritative," nor should it in my opinion, but speaking personally, I do 
strive to map as accurately as I possibly can.  Our data being widely and 
deeply respected is a great result OSM can be proud to continue.

I can't count the number of times I've (more recently) heard from Land Trust 
mapping professionals, local public GIS professionals, non-profit GIS 
professionals and more "OSM is a fantastic and amazing resource, there is 
nothing else like it and the world of mapping is a far richer place because it 
exists."  (Or something very much like that).

Bottom line:  please don't scoff at the possibility that your careful and 
accurate mapping might influence "official" or "authoritative" GIS data.  It 
can, it has, it does and it will continue to do so.

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

Re: [OSM-talk-fr] [SDIS/SAMU] Projet du mois défibrillateurs

[Jacques Lavignotte]

Merci Adrien.

J.

Le 02/09/2020 à 18:27, PanierAvide a écrit :

Pour l'argumentaire, tu peux reprendre ce qui est présent dans l'article :

- Diffuser l'info au plus grand nombre : plus les localisations 
ressortent dans diverses applis, plus il y a de chances d'avoir l'info 
au bon moment


- Contrainte légale : les propriétaires ont obligation de déclarer, info 
qui finit dans une base nationale ouverte, donc pas de problèmes "légal" 
à diffuser une base de DAE sous licence ouverte ou ODBL


- Possibilité de bénéficier de retours de la communauté sur les données 
libérées : DAE constatés déplacés sur le terrain, absents...


Cordialement,

Adrien P.

Le 02/09/2020 à 18:18, Jacques Lavignotte a écrit :



Le 02/09/2020 à 15:05, PanierAvide a écrit :

Bonjour,

C'est à tenter, de préférence par les contacts locaux.


C'est le S(D)IS (D comme département) 86 Je sais qu'ils ont une liste 
et un système de cartographie.


 De mon côté j'ai
fait les 4 SDIS de Bretagne, deux toujours en attente et les deux 
autres n'avaient pas


Pas de recencement des DAE ?

 (c'est le SAMU qui a et ça n'a pas été ouvert). Sur la
base de ça, je dirais plutôt tenter les SAMU, 


Je n'ai aucun indice sur le SAMU 86 mais peut-être une piste sur SAMU 
79 qui fait la promo de Sauv'Life.



::
Argumentaire ??
::

 En plus de leur signaler ce "Projet du mois" quels seraient les 
arguments à avancer pour les inciter à collaborer ?

J'ai les coordonnées d'un officier.


Adrien P.


Jacques


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


--
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: [OSM-talk-fr] [SDIS/SAMU] Projet du mois défibrillateurs

[PanierAvide]

Pour l'argumentaire, tu peux reprendre ce qui est présent dans l'article :

- Diffuser l'info au plus grand nombre : plus les localisations 
ressortent dans diverses applis, plus il y a de chances d'avoir l'info 
au bon moment


- Contrainte légale : les propriétaires ont obligation de déclarer, info 
qui finit dans une base nationale ouverte, donc pas de problèmes "légal" 
à diffuser une base de DAE sous licence ouverte ou ODBL


- Possibilité de bénéficier de retours de la communauté sur les données 
libérées : DAE constatés déplacés sur le terrain, absents...


Cordialement,

Adrien P.

Le 02/09/2020 à 18:18, Jacques Lavignotte a écrit :



Le 02/09/2020 à 15:05, PanierAvide a écrit :

Bonjour,

C'est à tenter, de préférence par les contacts locaux.


C'est le S(D)IS (D comme département) 86 Je sais qu'ils ont une liste 
et un système de cartographie.


 De mon côté j'ai
fait les 4 SDIS de Bretagne, deux toujours en attente et les deux 
autres n'avaient pas


Pas de recencement des DAE ?

 (c'est le SAMU qui a et ça n'a pas été ouvert). Sur la
base de ça, je dirais plutôt tenter les SAMU, 


Je n'ai aucun indice sur le SAMU 86 mais peut-être une piste sur SAMU 
79 qui fait la promo de Sauv'Life.



::
Argumentaire ??
::

 En plus de leur signaler ce "Projet du mois" quels seraient les 
arguments à avancer pour les inciter à collaborer ?

J'ai les coordonnées d'un officier.


Adrien P.


Jacques


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

Re: [OSM-talk-fr] [SDIS/SAMU] Projet du mois défibrillateurs

[Jacques Lavignotte]

Le 02/09/2020 à 15:05, PanierAvide a écrit :

Bonjour,

C'est à tenter, de préférence par les contacts locaux.


C'est le S(D)IS (D comme département) 86 Je sais qu'ils ont une liste et 
un système de cartographie.


 De mon côté j'ai
fait les 4 SDIS de Bretagne, deux toujours en attente et les deux autres 
n'avaient pas


Pas de recencement des DAE ?

 (c'est le SAMU qui a et ça n'a pas été ouvert). Sur la
base de ça, je dirais plutôt tenter les SAMU, 


Je n'ai aucun indice sur le SAMU 86 mais peut-être une piste sur SAMU 79 
qui fait la promo de Sauv'Life.



::
Argumentaire ??
::

 En plus de leur signaler ce "Projet du mois" quels seraient les 
arguments à avancer pour les inciter à collaborer ?

J'ai les coordonnées d'un officier.


Adrien P.


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

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

[Percherie OnDaNet]

Nickel je l'avais en tête mais je ne l'ai pas retrouvé sur le wiki

comme cela plus besoin de modifier le 80 en autre chose si la loi 
change. Si au niveau local le 80 à sauté, c'est obligatoirement un 
explicite avec signalisation verticale via source:maxspeed=sign


Pour ne plus y retoucher la combinaison maxspeed=FR:urban + 
source:maxspeed=FR:urban fonctionne bien.
Pour les sections à deux voies mieux vaut utiliser maxspeed=90 + 
source:maxspeed=sign ça lève tout ambiguïté et risque de faux positif. 
Exemple si un contributeur à indiqué 2 voie en ayant en tête "deux sens 
= deux voies". C'est souvent une erreur de débutant qui risque de 
générer des erreurs sur le routage.


En résumé, tout en automatique sauf si on n'est pas à 80 km/h.

Y a tellement de cas particulier qu'on pourrait en discuter encore 
quelques jours ;-)



Le 02/09/2020 à 10:34, Frédéric Rodrigo a écrit :

Le 02/09/2020 à 07:16, Gad Jo a écrit :
Préfère source:maxspeed=FR:urban + maxspeed=80 pour définir partout 
où la vitesse est à 80. Cela permettra facilement de modifier en 
masse les vitesses si on change les vitesses au niveau du pays 
(diminution à 70 ou rétablissement à 90)


Quand la vitesse est implicite, il y encore plus générique que mettre 
explicitement la vitesse. Mais plutôt :


maxspeed=FR:urban


Frédéric.




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

Re: [Talk-in] Virtual Mappy Hour - Sep'20

[Phani Kumar]

Hi OpenStreetMap,

How do we join is it a online session
I am new to open Street

On Wed, 2 Sep, 2020, 9:03 pm Chetan H A,  wrote:

> Hello all,
>
> We will connect on *12 Sep 2020, 9-10pm IST* and kick off our September
> Virtual Mappy Hours. This time we have *Rahul Reddy* who will be talking
> about his GSoC project on *nominatim* -
> https://www.openstreetmap.org/user/krahulreddy/diary/394064
>
> Please join -
> https://wiki.openstreetmap.org/wiki/India/Virtual_Mappy_Hours
>
> Thanks,
> Chetan
> (osm name: Chetan_Gowda)
>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[Talk-in] Virtual Mappy Hour - Sep'20

[Chetan H A]

Hello all,

We will connect on *12 Sep 2020, 9-10pm IST* and kick off our September
Virtual Mappy Hours. This time we have *Rahul Reddy* who will be talking
about his GSoC project on *nominatim* -
https://www.openstreetmap.org/user/krahulreddy/diary/394064

Please join - https://wiki.openstreetmap.org/wiki/India/Virtual_Mappy_Hours

Thanks,
Chetan
(osm name: Chetan_Gowda)
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[talk-cz] Import cyklotras a přidružených objektů

[Ondra Takács]

Zdravím,

jmenuji se Ondra Takács a jsem zaměstnanec Nadace Partnerství. Jedním z
našich projektů jsou cyklistické trasy, kde jsme do teď používali Google
mapu a mapy.cz a rádi bychom přešli na OSM. V rámci tohoto přechodu bychom
chtěli do OSM importovat data, která bychom pak využívali na našich
webových stránkách.

Toto je moje první zkušenost s OSM a rád bych se dozvěděl, jestli tato data
do OSM importovat můžeme. Taky bych se rád více seznámil s tím, jaké jsou v
české OSM komunitě zvyklosti v provádění rozsáhlejšího importu dat.

Nyní stručně popíšu, jaká data chceme importovat:

   1. cyklotrasy, jejich lokaci, název, popis a fotku,
   2. objekty jako restaurace, hotely, kampy, turistické cíle, u kterých
   bychom chtěli evidovat:


   - klasická metadata jako popis, kontaktní údaje, otevírací dobu, odkaz
  na web, fotky,
  - hodnocení tohoto objektu, kdo a kdy to hodnotil, počet hvězdiček
  1-5, slovní hodnocení.

Potřeboval bych vědět, jestli by bylo možné taková data do OSM importovat.
Které z těchto údajů je vhodné ukládat do OSM a které bychom měli evidovat
ve vlastní databázi?

Pro praktickou představu, k čemu to bude sloužit, tady dávám odkazy na naše
staré webové stránky, kde teď používáme jiné mapy:

   - https://www.cyklistevitani.cz/uvod.aspx
   - https://www.stezky.cz/mapa-stezek

Děkuji za odpověď
Ondra Takács
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] Attribution eaupotable.info

[European Water Project]

Salut Vincent,

Je reste dubitatif sur le site en lui même qui se nomme eaupotable et
qui en bas de page signale " Warning: We are unable to guarantee the
drinkability of the water. Most springs listed are known to be safe, but
few are regularly checked. "

> Je trouve qu'ils ont raison de signaler qu'ils ne peuvent en aucun
cas garantir la qualité de l'eau de chaque fontaine.  Notre "disclaimer" va
pas mal dans le même sens.

A bientôt,

Stuart



On Wed, 2 Sep 2020 at 09:24, Vincent Bergeot  wrote:

> Le 19/07/2018 à 08:44, Vincent Bergeot a écrit :
> > Le 11/07/2018 à 09:37, Vincent Bergeot a écrit :
> >> Le 11/07/2018 à 09:12, Johnparis a écrit :
> >>> https://eaupotable.info/en/contact/
> >>
> >> merci, je leur signale :)
> >
> > pour suivi, aucune réponse
>
> interpellé sur twitter
> (https://twitter.com/spoutnik/status/1301014314736742400, ben oui 2 ans,
> comme quoi les archives publiques c'est bien !!!) j'ai de nouveau
> utilisé la page contact pour dire que
> (https://eaupotable.info/en/fr-france) semblait en accord avec
> https://www.openstreetmap.org/copyright.
>
> Je reste dubitatif sur le site en lui même qui se nomme eaupotable et
> qui en bas de page signale " Warning: We are unable to guarantee the
> drinkability of the water. Most springs listed are known to be safe, but
> few are regularly checked. "
>
> Et coté données, non utilisable (du moins je n'ai trouvé aucune licence)
> et la création de nouveau point se fait en utilisant google
> (https://eaupotable.info/en/create) ce qui doit d'autant plus
> restreindre une éventuelle licence.
>
> pour suivi, puisque qu'un tweet est apparu :)
>
>
> --
> Vincent Bergeot
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Robert Grübler]

Am : Dienstag, 1. September 2020 00:52 schrieb grubernd 
[mailto:li...@mehrzweckraum.com]

> Das einfache am Bergsteigen ist hinaufzukommen.
> Das schwierige ist wieder gesund nach Hause zu kommen.
> Und das kann einem niemals eine Karte abnehmen.

Schön formuliert, deinen ganzen Beitrag stimme ich zu 100% zu.


> … aber in diesem Zusammenhang auch unrealistisch klassifizierenden Ansatz 
> sehe.

Welche Klassifikation ist worin unrealistisch? 
Wenn du einen meiner Beiträge meinst, ich beziehe mich auf das Wegehandbuch der 
Alpenvereine (DE, AT):
https://www.alpenverein.at/portal_wAssets/docs/berg-aktiv/wege_touren/wegehandbuch_digital.pdf
 
Kapitel „1.6 Das Wegekonzept von DAV und OeAV“, PDF-Seite 25
Kapitel „1.6.3 Wegeklassifizierung“, PDF-Seite 30

Weiters auf das inhaltlich weitgehend identische, aber detaillierter 
formulierte „Wander- und Bergwegekonzept des Landes Tirol“:
https://www.tirol.gv.at/fileadmin/themen/sport/berg-und-ski/berg_und_ski/TirolerBergwegekonzept2018.pdf
 
Kapitel „3. Richtlinien“, PDF-Seiten 7 bis 11
Kapitel "3.5.11 Wanderkarten" PDF-Seite 21


Liebe Grüße
Robert

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


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

Re: [OSM-talk-fr] [SDIS] Projet du mois défibrillateurs : c'est parti !

[PanierAvide]

Bonjour,

C'est à tenter, de préférence par les contacts locaux. De mon côté j'ai 
fait les 4 SDIS de Bretagne, deux toujours en attente et les deux autres 
n'avaient pas (c'est le SAMU qui a et ça n'a pas été ouvert). Sur la 
base de ça, je dirais plutôt tenter les SAMU, mais ça dépend peut-être 
des régions.


Cordialement,

Adrien P.

Le 02/09/2020 à 14:40, Jacques Lavignotte a écrit :

Bonjour,

essayer de collaborer avec le SDIS local est-il un axe sur ce projet 
ou est-ce vain du fait des concurrences entre les services d'urgence ?


J.






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

[OSM-ja] State of the Map Japan 2020 ONLINE募集案内

[Miura Hiroshi]

三浦です。

OpenStreetMapコミュニティイベントState of the Map Japan カンファレンス
を2020年11月7日(土)にオンラインで開催します。

https://stateofthemap.jp/2020/

現在OSMに関する発表者を募集しています。特設ページから応募をおねがいします。

マッピングのアイディア、コミュニティを拡大していく方法、ソフトウエアやサービスについて、その他、OSMに関することなら、ぜひあなたの考えを発表してほしいとおもいます。

奮ってご応募お願いします！

よろしくおねがいします。
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

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

[Jérôme Seigneuret]

implicite en rural dépend du nombre de voies sauf cas mentionné avec des
panneaux. Maintenant des département ont et vont remettre à 90km des
départementale. CF:
http://www.departements.fr/loi-mobilite-promulguee-retour-aux-90-kmh-possible-conditions

Donc avec c'est 80km par sens en voie unique. Sinon pour toute double voies
c'est 90km (implicite)
Le relèvement des voies de 10km doit être motivé. Donc avec panneaux
(explicite)

A+

Le mer. 2 sept. 2020 à 10:54,  a écrit :

> +0,9 ;-)
>
> > - sauf sur certaines portions de départementale dans certains
> départements
>
> Non, je crois que ça c'est une exception *explicite* car on a la liste et
> ça va figurer sur le terrain (je suppose). L'implicite c'est ce que dit le
> code de la route.
>
> En général dans les cas indiqués il y a des panneaux 90.
>
> > - On peut imaginer une route à double-sens avec un terre-plein
> temporaire pour un carrefour. Ce n'est pas pour autant que le long du
> terre-plein, la limite va passer à 90 km/h.
>
> En théorie tu as raison. En pratique
> ... Je ne sais si un gars a
> eu une offre spéciale pour réutiliser les anciens panneaux !
>
> Je réserve le source:maxspeed=FR:rural au 80. Les autres ça va être du
> source:maxspeed=sign.
>
> Jean-Yvon
> Le 02/09/2020 à 10:33, Eric SIBERT via Talk-fr - talk-fr@openstreetmap.org
> a écrit :
>
> +1 avec les avis précédents: en extra-urbain, l'implicite est devenu
> tellement incompréhensible qu'il vaut mieux coder explicitement.
>
> Par défaut c'est 80 km/h sur les chaussées à double sens:
> - sauf sur certaines portions de départementale dans certains départements
> - sauf quand il y a un une voie supplémentaire pour faire un créneau de
> dépassement
> - pareil pour les routes pour automobile (panneau C107) à double-sens?
> - On peut imaginer une route à double-sens avec un terre-plein temporaire
> pour un carrefour. Ce n'est pas pour autant que le long du terre-plein, la
> limite va passer à 90 km/h.
>
> Donc l'implicite est difficile à expliquer à l'humain et à l'ordinateur.
> Je ne sais même plus ce qu'il faut mettre pour source:maxspeed dans ces cas
> là.
>
> Eric
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [Talk-it] Google trekker

[Manuel]

Il Google Trekker era questo affare 
, con cui 
si poteva praticamente fare una StreetView di sentieri o luoghi accessibili solo a piedi. Legambiente ne ha 
fatti usare a dei suoi volontari (notizia 
) e penso che ci siano stati anche degli 
addetti stipendiati da Google che fotografavano luoghi altrimenti inaccessibili con la GoogleCar (ad 
esempio Venezia, e lo si vede in questo riflesso 
).
 Però, lo scopo principale non credo fosse mappare i sentieri, ma "allargare gli orizzonti" di 
StreetView a luoghi particolari.
Manuel
Il 02/09/2020 14:21, Maxxer via Talk-it ha scritto:

Il CAI di Bergamo so che ha portato il fardello di 40kg per qualche sentiero. 
C'era un modulo da compilare per fare richiesta. Comunque lo concedevano solo 
per sentieri di una certa rilevanza, non per ogni cavolata.

September 2, 2020 2:11 PM, "Cascafico Giovanni"  wrote:


Uno dei punti di forza di OSM rispetto alla controparte commerciale è
la mappatura dei sentieri. Ho trovato un'articolo [1] del 2014 in cui
il Touiring Club Italiano segnalava che il progetto "è ora pronto a
partire anche in Italia dove Google è sta reclutando trekker tra gli
enti turistici, le associazioni no profit, le università o le
organizzazioni di ricerca."

Ne sapete qualcosa? Chi ha partecipato?

[1]
https://www.touringclub.it/notizie-di-viaggio/google-trekker-anche-i-sentieri-sono-mappati-passo-dop
-passo/immagine/3

___
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: [OSM-talk-fr] [SDIS] Projet du mois défibrillateurs : c'est parti !

[Jacques Lavignotte]

Bonjour,

essayer de collaborer avec le SDIS local est-il un axe sur ce projet ou 
est-ce vain du fait des concurrences entre les services d'urgence ?


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-it] Google trekker

[Maxxer via Talk-it]

Il CAI di Bergamo so che ha portato il fardello di 40kg per qualche sentiero. 
C'era un modulo da compilare per fare richiesta. Comunque lo concedevano solo 
per sentieri di una certa rilevanza, non per ogni cavolata. 

September 2, 2020 2:11 PM, "Cascafico Giovanni"  wrote:

> Uno dei punti di forza di OSM rispetto alla controparte commerciale è
> la mappatura dei sentieri. Ho trovato un'articolo [1] del 2014 in cui
> il Touiring Club Italiano segnalava che il progetto "è ora pronto a
> partire anche in Italia dove Google è sta reclutando trekker tra gli
> enti turistici, le associazioni no profit, le università o le
> organizzazioni di ricerca."
> 
> Ne sapete qualcosa? Chi ha partecipato?
> 
> [1]
> https://www.touringclub.it/notizie-di-viaggio/google-trekker-anche-i-sentieri-sono-mappati-passo-dop
> -passo/immagine/3
> 
> ___
> 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] Google trekker

[Martin Koppenhoefer]

sent from a phone

> On 2. Sep 2020, at 14:13, Cascafico Giovanni  wrote:
> 
> Ne sapete qualcosa?


sembrerebbe uno dei tentativi a farci concorrenza nei nostri ambiti di forza

visto che non si sente niente di questo è probabilmente fallito ;-)


Ciao Martin 


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

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

[Alessandro Sarretta]

On 02/09/20 11:56, Federico Cortese wrote:

On Wed, Sep 2, 2020 at 11:46 AM Martin Koppenhoefer
 wrote:

On 2. Sep 2020, at 11:01, Cascafico Giovanni  wrote:

Nei frequenti casi di mancata corrispondenza OSM-dataset, il conflator
(in base ai parametri che gli fornisco) può seguire una di queste 3
strade:

- inserire un tag fixme con testo tipo inesistente/abbattuto o
pragmaticamente "non presente nel dataset di input
- marcare l'oggetto per la successiva rimozione nel secondo passaggio
del conflator
- non fare nulla


non so se ho capito bene, variante 2 propone di eliminare alberi da 
OpenStreetMap che non sono nel dataset?


Direi meglio "non fare nulla".
In fin dei conti il dataset ci dice solo se l'albero è "monumentale",
quindi ok aggiungere alberi non mappati, ok aggiungere le informazioni
ad alberi già mappati, ma per quelli già mappati con
denotation=natural_monument, che però non sono nel dataset, non
conviene aggiungere fixme, tantomeno cancellarli. Si vede che per chi
li ha mappati sono natural_monument ma per il MIPAAF no o non ancora.


In realtà tra gli allegati dei vari Decreti ministeriali (qui l'ultimo 
https://www.politicheagricole.it/flex/cm/pages/ServeBLOB.php/L/IT/IDPagina/15808) 
ce n'è uno con l'elenco degli alberi cancellati dall'elenco per morte, 
abbattimento o perdita delle caratteristiche di monumentalità 
(deperimento): 
https://www.politicheagricole.it/flex/cm/pages/ServeAttachment.php/L/IT/D/e%252F5%252Fd%252FD.b9c017d9d93a4983a6db/P/BLOB%3AID%3D15808/E/pdf


Probabilmente se si facesse l'incrocio tra quelli ufficialmente 
cancellati dall'elenco e quelli presenti in OSM e non nell'elenco 
aggiornato potremmo trovarne qualcuno da eliminare (o, meglio ancora, 
mettere una nota esplicita che chieda di confermare abbattimento/morte...)


Ale

--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com 

Research information:

 * Google scholar profile
   
 * ORCID 
 * Research Gate 
 * Impactstory 

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

[Talk-it] Google trekker

[Cascafico Giovanni]

Uno dei punti di forza di OSM rispetto alla controparte commerciale è
la mappatura dei sentieri. Ho trovato un'articolo [1] del 2014 in cui
il Touiring Club Italiano segnalava che il progetto "è ora pronto a
partire anche in Italia dove Google è sta reclutando trekker tra gli
enti turistici, le associazioni no profit, le università o le
organizzazioni di ricerca."

Ne sapete qualcosa? Chi ha partecipato?



[1] 
https://www.touringclub.it/notizie-di-viaggio/google-trekker-anche-i-sentieri-sono-mappati-passo-dopo-passo/immagine/3

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

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

[Cascafico Giovanni]

Lasciare in fixme con "l'albero potrebbe essere abbattuto o
declassificato" oppure "non presente in dataset mipaaf", potrebbe
stimolare un mappatore a controllarne la correttezza oppure a
segnalare l'albero al mipaaf. Entrambe azioni utili.

Mica scriviamo...
fixme=brutto idiota: questo albero non esiste, vai al SERT!

L'opzione di cancellarli non l'ho mai presa in considerazione,
elencavo solo le possibilità del tool conflator.

Il 02/09/20, Martin Koppenhoefer ha scritto:
> Am Mi., 2. Sept. 2020 um 11:57 Uhr schrieb Federico Cortese <
> cortese...@gmail.com>:
>
>> Direi meglio "non fare nulla".
>> In fin dei conti il dataset ci dice solo se l'albero è "monumentale",
>> quindi ok aggiungere alberi non mappati, ok aggiungere le informazioni
>> ad alberi già mappati, ma per quelli già mappati con
>> denotation=natural_monument, che però non sono nel dataset, non
>> conviene aggiungere fixme, tantomeno cancellarli. Si vede che per chi
>> li ha mappati sono natural_monument ma per il MIPAAF no o non ancora.
>
>
>
> concordo pienamente, probabile che ci siano altri alberi che comunemente si
> considererebbero monumentali, ma che attualmente il MIPAAF non ha (ancora?)
> sulla sua lista.
> Idealmente, nel caso di associazione di dati dal dataset ad un albero già
> mappato in osm (per lo più saranno oggetti del tipo "natural=tree" senza
> informazioni aggiuntive?) ci sarebbe anche da controllare in loco se i dati
> corrispondono a questo albero (species, grandezza, ecc.), visto che abbiamo
> identificato alberi spostati di un chilometro rispetto alla "nostra
> realtà".
>
> Ciao
> Martin
>

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

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

[Dino Michelini]

cato alberi spostati di un chilometro rispetto alla "nostra realtà".

Ciao
Martin
-- parte successiva ------
Un allegato HTML è stato rimosso...
URL: 
<http://lists.openstreetmap.org/pipermail/talk-it/attachments/20200902/819abb30/attachment-0001.htm>

--

Subject: Chiusura del digest

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


--

Fine di Digest di Talk-it, Volume 166, Numero 5
***


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

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

[Martin Koppenhoefer]

Am Mi., 2. Sept. 2020 um 11:57 Uhr schrieb Federico Cortese <
cortese...@gmail.com>:

> Direi meglio "non fare nulla".
> In fin dei conti il dataset ci dice solo se l'albero è "monumentale",
> quindi ok aggiungere alberi non mappati, ok aggiungere le informazioni
> ad alberi già mappati, ma per quelli già mappati con
> denotation=natural_monument, che però non sono nel dataset, non
> conviene aggiungere fixme, tantomeno cancellarli. Si vede che per chi
> li ha mappati sono natural_monument ma per il MIPAAF no o non ancora.



concordo pienamente, probabile che ci siano altri alberi che comunemente si
considererebbero monumentali, ma che attualmente il MIPAAF non ha (ancora?)
sulla sua lista.
Idealmente, nel caso di associazione di dati dal dataset ad un albero già
mappato in osm (per lo più saranno oggetti del tipo "natural=tree" senza
informazioni aggiuntive?) ci sarebbe anche da controllare in loco se i dati
corrispondono a questo albero (species, grandezza, ecc.), visto che abbiamo
identificato alberi spostati di un chilometro rispetto alla "nostra realtà".

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

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

[Mateusz Konieczny via Talk-au]

Sep 2, 2020, 06:06 by thesw...@gmail.com:

> On 2/09/2020 10:38 am, Graeme Fitzpatrick wrote:
>
>>
>> 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?
>>
>
> Sigh.
>
> He is a serial offender:
>
> https://lists.openstreetmap.org/pipermail/talk-au/2019-October/013009.html
>
> There was no discussion. I'd suggest that the changes to the wiki page should 
> be reverted.
>
I posted on their talk page on Wiki with request to explain what is the source 
of change +
mailing list links.

See 
https://wiki.openstreetmap.org/w/index.php?title=User_talk:Aaronsta=2028532=1185639

BTW, if he is serial offender why noone ever commented on their talk page?
Maybe it would help and they have some good point?

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

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

[Federico Cortese]

On Wed, Sep 2, 2020 at 11:46 AM Martin Koppenhoefer
 wrote:
>
> > On 2. Sep 2020, at 11:01, Cascafico Giovanni  wrote:
> >
> > Nei frequenti casi di mancata corrispondenza OSM-dataset, il conflator
> > (in base ai parametri che gli fornisco) può seguire una di queste 3
> > strade:
> >
> > - inserire un tag fixme con testo tipo inesistente/abbattuto o
> > pragmaticamente "non presente nel dataset di input
> > - marcare l'oggetto per la successiva rimozione nel secondo passaggio
> > del conflator
> > - non fare nulla
>
>
> non so se ho capito bene, variante 2 propone di eliminare alberi da 
> OpenStreetMap che non sono nel dataset?
>

Direi meglio "non fare nulla".
In fin dei conti il dataset ci dice solo se l'albero è "monumentale",
quindi ok aggiungere alberi non mappati, ok aggiungere le informazioni
ad alberi già mappati, ma per quelli già mappati con
denotation=natural_monument, che però non sono nel dataset, non
conviene aggiungere fixme, tantomeno cancellarli. Si vede che per chi
li ha mappati sono natural_monument ma per il MIPAAF no o non ancora.

Ciao,
Federico

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

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

[Martin Koppenhoefer]

sent from a phone

> On 2. Sep 2020, at 11:01, Cascafico Giovanni  wrote:
> 
> Nei frequenti casi di mancata corrispondenza OSM-dataset, il conflator
> (in base ai parametri che gli fornisco) può seguire una di queste 3
> strade:
> 
> - inserire un tag fixme con testo tipo inesistente/abbattuto o
> pragmaticamente "non presente nel dataset di input
> - marcare l'oggetto per la successiva rimozione nel secondo passaggio
> del conflator
> - non fare nulla


non so se ho capito bene, variante 2 propone di eliminare alberi da 
OpenStreetMap che non sono nel dataset?

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

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

[Cascafico Giovanni]

Ho eliminato dal potenziale import i gruppi di alberi ed i filari
perchè non so come gestire geometrie diverse, per cui il conflator non
trova la corrispondenza dei due alberi OSM nel dataset in input.

Nei frequenti casi di mancata corrispondenza OSM-dataset, il conflator
(in base ai parametri che gli fornisco) può seguire una di queste 3
strade:

- inserire un tag fixme con testo tipo inesistente/abbattuto o
pragmaticamente "non presente nel dataset di input
- marcare l'oggetto per la successiva rimozione nel secondo passaggio
del conflator
- non fare nulla

Sottolineo che queste operazioni non le fa online, in quanto è sempre
necessario riprocessare tutti gli audit eseguiti dai mappatori per
ottenere un file .osm per la verifica finale.

Ricordo che qui [1] trovate uno schema che chiarisce l'intero processo.

[1] 
https://wiki.openstreetmap.org/w/images/thumb/f/fe/Conflate_audit_chart.jpg/800px-Conflate_audit_chart.jpg



Il 02/09/20, Andrea Musuruane ha scritto:
> C'è anche un altro problema. Nel dataset originario su Gmaps, è presente un
> gruppo di alberi in piazza S. Eusebio a Vercelli,. Nel file di conflation
> non sono presenti e i due indicati in piazza S. Eusebio (inseriti da un
> import mal fatto precedente) vengono indicati come "albero non presente in
> dataset MIPAAF: abbattuto/declassificato?".
>
> Ciao,
>
> Andrea
>
>
> On Tue, Sep 1, 2020 at 7:15 PM Volker Schmidt  wrote:
>
>> 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
>>
>

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

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

[osm . sanspourriel]

+0,9 ;-)

> - sauf sur certaines portions de départementale dans certains
départements

Non, je crois que ça c'est une exception *explicite* car on a la liste
et ça va figurer sur le terrain (je suppose). L'implicite c'est ce que
dit le code de la route.

En général dans les cas indiqués il y a des panneaux 90.

> - On peut imaginer une route à double-sens avec un terre-plein
temporaire pour un carrefour. Ce n'est pas pour autant que le long du
terre-plein, la limite va passer à 90 km/h.

En théorie tu as raison. En pratique
... Je ne sais si un gars a
eu une offre spéciale pour réutiliser les anciens panneaux !

Je réserve le source:maxspeed=FR:rural au 80. Les autres ça va être du
source:maxspeed=sign.

Jean-Yvon

Le 02/09/2020 à 10:33, Eric SIBERT via Talk-fr -
talk-fr@openstreetmap.org a écrit :

+1 avec les avis précédents: en extra-urbain, l'implicite est devenu
tellement incompréhensible qu'il vaut mieux coder explicitement.

Par défaut c'est 80 km/h sur les chaussées à double sens:
- sauf sur certaines portions de départementale dans certains
départements
- sauf quand il y a un une voie supplémentaire pour faire un créneau
de dépassement
- pareil pour les routes pour automobile (panneau C107) à double-sens?
- On peut imaginer une route à double-sens avec un terre-plein
temporaire pour un carrefour. Ce n'est pas pour autant que le long du
terre-plein, la limite va passer à 90 km/h.

Donc l'implicite est difficile à expliquer à l'humain et à
l'ordinateur. Je ne sais même plus ce qu'il faut mettre pour
source:maxspeed dans ces cas là.

Eric


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

[majkaz]

Jo, přesně z toho důvodu se přikláním k tomu, do značky name nehrabat a případně nechat i 
prázdnou u nově zadávaných bodů. Kompletní název do samostatné značky, jen se dohodnout 
na tom, zda ta ref_name, která se mi na to líbí nejvíc, je v pořádku. Zrovna tady by ale 
ta verze s ",," měla být v pořádku a nevyhazovat chyby.
Informace v datech bude. A nic nebrání tomu, používané jméno (tedy značku name) 
doplnit na místě podle skutečnosti.
Přínos ten import bude mít tak jako tak, už jen v tom, že nám zastávky nebudou 
chybět v datech. To je momentálně případ ve spoustě menších obcí. Ideálně to 
stejně časem chce napasovat na linky dopravy nebo minimálně přiřadit ke 
konkrétnímu provozovateli, ale to z těch dat kraje nejde.
 
Majka
__

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


- zastávky mimo Prahu - všechny varianty - jedna část (Měchenice), dvě (Davle, 
Sloup) i všechny tři (Davle, Sloup, U jeřábu)
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

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

[Frédéric Rodrigo]

Le 02/09/2020 à 07:16, Gad Jo a écrit :
Préfère source:maxspeed=FR:urban + maxspeed=80 pour définir partout où 
la vitesse est à 80. Cela permettra facilement de modifier en masse 
les vitesses si on change les vitesses au niveau du pays (diminution à 
70 ou rétablissement à 90)


Quand la vitesse est implicite, il y encore plus générique que mettre 
explicitement la vitesse. Mais plutôt :


maxspeed=FR:urban


Frédéric.



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

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

[Eric SIBERT via Talk-fr]

+1 avec les avis précédents: en extra-urbain, l'implicite est devenu 
tellement incompréhensible qu'il vaut mieux coder explicitement.


Par défaut c'est 80 km/h sur les chaussées à double sens:
- sauf sur certaines portions de départementale dans certains 
départements
- sauf quand il y a un une voie supplémentaire pour faire un créneau de 
dépassement

- pareil pour les routes pour automobile (panneau C107) à double-sens?
- On peut imaginer une route à double-sens avec un terre-plein 
temporaire pour un carrefour. Ce n'est pas pour autant que le long du 
terre-plein, la limite va passer à 90 km/h.


Donc l'implicite est difficile à expliquer à l'humain et à l'ordinateur. 
Je ne sais même plus ce qu'il faut mettre pour source:maxspeed dans ces 
cas là.


Eric


___
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

[Mikoláš Štrajt]

Ten dlouhý název ve formátu ,<Část obce>, je
oficiální název. Předpokládám, že se používá při komunikaci dopravců s
dopravními úřady atd...




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



V okolí Prahy se to (v terénu / v autobusech) označuje takto:




- zastávky na území Prahy - jenom jedna (poslední) část - např. Zbraslavské
náměstí (podobně to používá MHD v Mladé Boleslavi)


- zastávky mimo Prahu - všechny varianty - jedna část (Měchenice), dvě
(Davle, Sloup) i všechny tři (Davle, Sloup, U jeřábu)




Pro větší zmatení některé autobusy píšou cílovou stanici "Praha, Smíchovské
nádraží" a některé jenom "Smíchovské nádraží" (tohle asi záleží na dopravci
nebo čertví čem).





Předpokládám, že v okolí Budějovic to bude více méně to samé.





--


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

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

[mbranco2]

Se proponi di cambiarla, indica quali frasi modificheresti o sostituiresti
in [1]; io personalmente non toccherei neanche una virgola.
Per i pigri che non hanno voglia di leggere tutta la pagina, riporto parti
significative per quanto si sta discutendo:
**
*AMBITO*
**
*-  uso di funzioni trova-e-sostituisci negli editor standard come JOSM
oppure ricerche usando servizi come Overpass API e modifiche conseguenti
fatte senza il controllo sui singoli elementi; *
*-   cambiare i tag manualmente su larga scala senza un'adeguata revisione*
* Anche se stai per modificare i tag di un grande numero di oggetti
sistematicamente e non pensi che sia una modifica automatica che ricade
sotto questo codice di condotta, è comunque una buona idea discutere prima
le tue modifiche. *
*Uso problematico*
* Usare uno strumento per affermare uno standard, o la tua personale
interpretazione di uno standard, quando potrebbero esserci giustificati
motivi per altre interpretazioni o dove lo standard non rispecchia la
pratica comune. In particolare è un problema quando una persona, o un
piccolo gruppo di persone, stabiliscono uno standard di codifica e poi
usano processi automatici per applicarlo nel database senza una
consultazione appropriata. Tieni a mente che la Wiki non deve essere usata
come la definizione dell'unico modo corretto di assegnare i tag, e che non
è accettabile usare la wiki come giustificazione per modifiche massive ai
dati senza una adeguata consultazione.*

*.**Documenta e discuti i tuoi piani*



*Se hai in mente di fare una modifica automatica, prima discutine e
documentala. La documentazione deve essere inserita nella wiki e la
proposta discussa nelle opportune mailing list...Di solito si documentano
le modifiche che si vogliono fare in una pagina wiki in inglese con nome
"Automated edits/username" (dove username è il nome utente OSM dell'account
con cui saranno eseguite le modifiche (pensa adesso al nome, così non
dovrai rinominare la pagina dopo), e aggiungila a Category:Automated edits
log .*


*La documentazione deve riportare: *

[1] https://wiki.openstreetmap.org/wiki/IT:Automated_Edits_code_of_conduct



Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Il giorno mer 2 set 2020 alle ore 07:09 canfe  ha
scritto:

> “La legge è fatta per gli uomini, non sono gli uomini fatti per la Legge”
>
>
>
> Pertanto cambiamola.
>
>
>
> *Da:* Marco Minghini [mailto:marco.minghin...@gmail.com]
> *Inviato:* martedì 1 settembre 2020 21:57
> *A:* openstreetmap list - italiano
> *Oggetto:* Re: [Talk-it] R: Edit automatici su nome strade
>
>
>
> 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 mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[osm . sanspourriel]

Bonjour,

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

L'accès aux courées est en accès libre (aux piétons) en grosse
majorité. Donc ce ne sont pas des types "appartement" , celle que je
connais ont bien leur propre boite au lettre à la porte par exemple :
le facteur doit entrer dans la courée.
L'adresse officielle de la rue semble être le nom de la courée, mais
dans les faits : sur les courriers : il ya intérêt à indiquer la rue
principale si le facteur est en vacances ou est malades par exemple.

Sinon : l'entrée de la courée : bonne ou mauvaise idée ?


Si les boîtes-aux-lettres sont au niveau de chaque maison, alors une
courée c'est clairement une associatedStreet.

L'entrée de la courée, c'est comme déjà dit le point d'accès, AMHA ça
n'en fait pas partie mais ça se discute.

L'entrée de la courée, c'est à mettre au niveau de la rue d'accès (pas
la courée).

A mettre ou pas mais comme ça figure sur le terrain, je dirais à mettre.

Je fais l'hypothèse qu'un facteur remplaçant saura utiliser un plan,
dérivé d'OSM par exemple, pour localiser les courées et leurs entrées.

Dans ton exemple on voit qu'il y a deux entrées, je suppose que le
facteur va parcourir la courée une seule fois et non deux demies fois
aller retour. Et donc le numéro sur la rue principale ne sera pas celui
qui figurerait sur la seconde ligne de rue mais celui qui l'arrange.
L'un ou l'autre. Il entrera par un ressortira par l'autre.

Jean-Yvon



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

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

[Vincent Bergeot]

Merci Yves,
à noter pour expliquer peut-être la diffusion sur la liste qu'il est 
explicitement fait référence à OSM, je cite :


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



Vincent


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

Re: [OSM-talk-fr] Attribution eaupotable.info

[Vincent Bergeot]

Le 19/07/2018 à 08:44, Vincent Bergeot a écrit :

Le 11/07/2018 à 09:37, Vincent Bergeot a écrit :

Le 11/07/2018 à 09:12, Johnparis a écrit :

https://eaupotable.info/en/contact/


merci, je leur signale :)


pour suivi, aucune réponse


interpellé sur twitter 
(https://twitter.com/spoutnik/status/1301014314736742400, ben oui 2 ans, 
comme quoi les archives publiques c'est bien !!!) j'ai de nouveau 
utilisé la page contact pour dire que 
(https://eaupotable.info/en/fr-france) semblait en accord avec 
https://www.openstreetmap.org/copyright.


Je reste dubitatif sur le site en lui même qui se nomme eaupotable et 
qui en bas de page signale " Warning: We are unable to guarantee the 
drinkability of the water. Most springs listed are known to be safe, but 
few are regularly checked. "


Et coté données, non utilisable (du moins je n'ai trouvé aucune licence) 
et la création de nouveau point se fait en utilisant google 
(https://eaupotable.info/en/create) ce qui doit d'autant plus 
restreindre une éventuelle licence.


pour suivi, puisque qu'un tweet est apparu :)


--
Vincent Bergeot


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

Re: [talk-au] Suburbs & admin boundaries stopping streets being found?

[Warin]

On 30/8/20 3:40 pm, Graeme Fitzpatrick wrote:
Having a problem with OSMAND that I think could be related back to the 
way data has been entered, or later defined, in OSM?


Playing with OSMAND yesterday & searched for a local street but it 
came back "not found". Tried a number of others with some found & 
others not. Then tried changing the search town from "Gold Coast" to 
individual suburbs & all the "missing" streets in that suburb were 
then found OK?


If you'd like to please try yourself, in OSMAND, please set your city 
/ town to Gold Coast, then search Dawn Parade, Honeyeater Drive & Rio 
Vista Boulevard. There should be nothing found for the first two, but 
Rio Vista should appear but with only two results - intersections with 
Furlong Street & Cleland Crescent.


If you then set the city / town to Miami, Dawn Parade will show; 
Burleigh Waters will find Honeyeater Drv & Broadbeach Waters will show 
all of the Rio Vista Blvd results (~50 of them!)


BTW, they can all be found fine in OSM itself eg Dawn Parade Miami 
gives 
https://www.openstreetmap.org/way/182163166#map=17/-28.06847/153.43806


I think there may be two things at play here?

Only a few Gold Coast suburbs, including these ones, have had their 
admin boundaries mapped (incidentally, as an aside, they've been 
mapped as admin_level=10 - should they be =9?) eg 
https://www.openstreetmap.org/relation/973018.


In addition, the overall Gold Coast LGA boundary hasn't been mapped.

Does that sound feasible?

If so, what's the fix? It would appear that mapping an admin boundary 
has convinced OSMAND that that area isn't part of the Gold Coast any 
more? Would mapping the Gold Coast LGA as admin_level=8 resolve it?


Or is this just another OSMAND problem? :-(



Think it is OSMand.

In NSW I tried some searches and could not find some streets.

However .. if I first searched for a town/suburb/hamlet and then 'went 
there' it would find the street... strange.


Admin levels of 6 and 10 were present for these .. did not test further.




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

Re: [OSM-talk-fr] Prendre les escaliers à vélo

[Simon Réau]

Bonjour,

Chez Geovelo nous interprétons de la même manière que toi. Escalier
interdit sauf si bicycle=yes ou ramp:bicycle=yes. Peut être peux tu les
contacter pour qu'il modifie leur algo.

Simon REAU
GEOVELO
www.geovelo.fr
simon.r...@geovelo.fr
Tél : 06 77 15 59 86
1 Impasse du Palais, 37000 Tours 




Le sam. 29 août 2020 à 10:59, blef  a écrit :

> Les "bandes roulables à côté sans marches" sont (ou devraient être)
> taguées avec l'attribut ramp:bicycle=yes
> 
> Mais les routeurs en question ne se limitent pas à ces (rares) cas pour
> créer leurs itinéraires.
>
> Le 28/08/2020 à 23:32, Philippe Verdy a écrit :
>
> Sauf les escaliers à marches près  peu pentues et pas trop hautes (pas
> plus que les ralentisseurs sur les rues ou aires de parking) ou ceux qui
> disposent d'une bande roulable à côté sans marches et de zones planes
> d'arrêt. Assimilables aux voies (lanes) sur les rues/routes (highways=*
> aussi) s'il n'y a pas de réelle séparation physique entre l'escalier piéton
> et la bande roulante, et donc pas forcément détaillés par des "ways" OSM
> séparés.
>
>
> Le ven. 28 août 2020 à 18:44, blef  a écrit :
>
>> Bonjour,
>>
>> Je m'aperçois qu'en faisant une recherche d'itinéraire en mode vélo, que
>> ce soit avec GraphHopper ou OSRM, on m'envoie sans vergogne sur des
>> escaliers.
>> Pourtant, d'après le wiki
>> , le tag
>> highway=steps implique access=no + foot=yes, donc implicitement bicycle=no,
>> ce qui me semble normal, moi qui n'ai pas pour habitude de descendre (ou
>> monter) les escaliers à vélo!
>> Me confirmez vous que le tag highway=steps ne nécessite pas d'ajouter
>> bicycle=no et donc que les routeurs n'appliquent pas correctement les
>> conditions d'accès dans ce cas?
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Denis Chenu via Talk-fr]

Bonjour,

Sur le libellé «officiel», ce n'est pas constant.

Exemple avec
- 595121761Y :
1. libellé BANO : DESCHAMPS 19 BD DE METZ (j'ai indiqué "Cours
Deschamps, 19 Boulevard de Metz", faut que j'enlève le s de Cours). 2
entrée différentes pour la même cour (en fait 2 voies spéarées)
2. libellé BAN (ban-housenumber-a9713453c5374037b02b147efd833360) Nom du
groupe : COUR DESCHAMPS, le BANO est placé juste à coté sur
https://guichet-adresse.ign.fr/map/ (doublon)
3. Cadastre "Cour Descamp"
- 595122353S
1. libellé BANO "GHESQUIERES RUE DE LA VIGN", j'ai indiqué "Cour
Ghesquieres, 71 bis Rue de la Vigne"
2. libellé BAN (ban-group-fdbe969afb5d46e79fb93652e15c5309) Nom du
groupe : "COUR GHESQUIERES"
3. Cadastre "Cour Ghesquieres Vanderbroeck"
- 595122362B
1. Libellé BANO "CRS GOVAERE RUE DE L EPEULE", j'ai indiqué "Cour
Govaere, Rue de l'Épeule"
2. BAN : "COUR GOVAERE"
3. Cadastre : "Cour Govaere"

En général : les panneaux à l'entrée indique : le nom de la courée, et
certaines fois le numéro de la rue principale. Si la cour Ghesquieres
posséde une porte : c'est exceptionnel.
La majorité c'est comme https://www.openstreetmap.org/way/842114374 (125
rue de l'épeule, cour Govaere, BANO 595122362B) : panneau nom + numéro
rue sur entrée libre sans porte.

L'accès aux courées est en accès libre (aux piétons) en grosse majorité.
Donc ce ne sont pas des types "appartement" , celle que je connais ont
bien leur propre boite au lettre à la porte par exemple : le facteur
doit entrer dans la courée.
L'adresse officielle de la rue semble être le nom de la courée, mais
dans les faits : sur les courriers : il ya intérêt à indiquer la rue
principale si le facteur est en vacances ou est malades par exemple.

Sinon : l'entrée de la courée : bonne ou mauvaise idée ?

Denis


Le 02/09/2020 à 05:38, Philippe Verdy a écrit :
> 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 :
>
> 

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

[Andrea Musuruane]

C'è anche un altro problema. Nel dataset originario su Gmaps, è presente un
gruppo di alberi in piazza S. Eusebio a Vercelli,. Nel file di conflation
non sono presenti e i due indicati in piazza S. Eusebio (inseriti da un
import mal fatto precedente) vengono indicati come "albero non presente in
dataset MIPAAF: abbattuto/declassificato?".

Ciao,

Andrea


On Tue, Sep 1, 2020 at 7:15 PM Volker Schmidt  wrote:

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

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

[Cascafico Giovanni]

Il 01/09/20, Marco Gaiarin ha scritto:
> 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...

Caso interessante... era frutto di import da xls regionale,
evidentemente nella versione predente la posizione era corretta.

Ciò confermerebbe la necessità di audit preliminari, magari regionali.

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

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

[Jean-Christophe Becquet]

Le 01/09/2020 à 19:13, Georges Dutreix via Talk-fr a écrit :
> 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

Bonjour,

Moi aussi, il m'est arrivé de découper des ronds points pour décrire des
itinéraires cyclables. Je lis donc avec intérêt cette discussion pour
les prochaines fois.

Bonne journée

JCB
-- 
WLM : le concours mondial de photos libres Wiki Loves Monuments
http://www.apitux.org/index.php?2016/02/03/252-wlm-le-concours-mondial-de-photos-libres-wiki-loves-monuments

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
2 chemin du Tivoli - 04000 Digne-les-Bains
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===

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

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

[Topographe Fou]

  Bonjour,Suis entièrement d'accord pour source:maxspeed + maxspeed , cela représente bien la réalité et est explicite ce qui est toujours plus clair. En plus c'est un binôme qui peut aider à détecter des incohérences (je crois même me souvenir qu'il existe une analyse Osmose sur ce point) et donc erreurs de saisies ou évolutions du code de la route comme expliqué précédemment. Personnellement je saisie toujours un maxspeed explicite et agrémente occasionnellement d'un source:maxspeedPar ailleurs sémantiquement parlant le préfixe source:x n'a pas de sens pour moi si le tag x n'a pas été défini. Le préfixe source: dénote de l'origine d'un tag avant de dénoter sa valeur. C'est ma compréhension, laquelle peut être contestée. Mais c'est aussi le sens de la première phrase de description du wiki :The source:maxspeed=* tag records the source of a road's maximum speed limit as provided in the maxspeed=* tag to assist with verifiability and maintenance.  LeTopographeFou   De: perche...@toutenkamion.netEnvoyé: 2 septembre 2020 7:17 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] maxspeed par défaut  J'envisage plutôt l'inverse en anticipant un énième changement de règle au niveau national. Mieux vaut prévenir que guérir. Cela facilitera les corrections en masse si on indique la source.Préfère source:maxspeed=FR:urban + maxspeed=80 pour définir partout où la vitesse est à 80. Cela permettra facilement de modifier en masse les vitesses si on change les vitesses au niveau du pays (diminution à 70 ou rétablissement à 90)Pour tout les autres cas même les portions où c'est sur tout un département que les routes sont repassée à 90, indique une autre source comme source:maxspeed=sign ou source:maxspeed=FR:zone** (souvent 30, parfois 20 ou 50) quand les mairies n'utilise pas les panneaux zone de rencontre ou limitation 50 pour les lotissement hors agglo.Plus d'info et exemple sur https://wiki.openstreetmap.org/wiki/FR:Key:source:maxspeedLe September 1, 2020 11:15:53 PM UTC, Yannick  a écrit :
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 voiesd'insertion, etc.De nombreuses portions ont une limite de vitesse implicite car il n'ya pas de panneau limitant la vitesse, et les règles généraless'appliquent (R413-2). Le problème est que ces règles sont malconnues, et presque tout a été mal mappé avec maxspeed=80. Pourl'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 toutde même taguer qqch pour faire la différence entre une route demaxspeed inconnue, et une route de maxspeed implicite. Ma question estdonc:Est-ce qu'utiliser source:maxspeed=FR:rural sans maxspeed=* est unebonne pratique?PS: Les règles du code de la route sont si mal connues quehttps://wiki.openstreetmap.org/wiki/FR:Key:maxspeed#Limitation_de_vitessecontient une erreur de 20 km/h.Marc MongenetBonsoir,L'implicite est désormais quasi impossible à deviner. Prends lesnationales à 80 et des portions de départementales à 90. Je me mets à laplace de l'étranger pour qui c'est pire qu'un casse-tête chinois. Onfinit par ne plus savoir la limite en vigueur sur telle ou telle portionde route.Je suis donc partisan de mettre systématiquement le maxspeed=* au moinsc'est clairement renseigné sans équivoque possible.Amitiés-- 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

[talk-cz] Zastupce OSM ČR u Nadace OSM

[Tom Ka]

Ahoj,

vzhledem k tomu, že se spolek OSM ČR stal oficiálním zastoupením
Nadace OSM, máme možnost mít svého zástupce v poradním sboru rady
Nadace OSM (advisory board). Jedná se o poradní funkci pro radu
nadace, komunikace je přes mail list s malým provozem.

Měl by někdo zájem o tuto pozici? Nemusí být špatné, být u zdroje
informací, když nic jiného, tak pro propojení na talk-cz kde lze
sebrat názor komunity a presentovat ho zpět radě.

Diky tom.k

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