Re: [talk-au] Are Health Centres, hospitals

[Graeme Fitzpatrick]

On Fri, 4 Sep 2020 at 13:22, Michael James  wrote:

>
>
> Not sure QAS offers any walk up facilities anymore, the local one here has
> a phone out the front to call for help.
>

Think it may depend a lot on the size of the town?

On Fri, 4 Sep 2020 at 13:28, Andrew Davidson  wrote:

>
> I only get 202 for QLD https://overpass-turbo.eu/s/XGU. Are you searching
> for something other than amenity=hospital and healthcare=hospital ?
>

I searched just amenity=hospital.

Maybe I'm mis-reading the results as it came back:
Loaded – nodes: 2092, ways: 159, relations: 4
Displayed – pois: 72, lines: 0, polygons: 150
So does that make 2255 / 222 / or a different tally?

On Fri, 4 Sep 2020 at 15:11, cleary  wrote:

>
>  If this is all the community has and they regard it as their "hospital"
> then I feel reluctant to take it away.
>

Fair enough, & I must admit to having that same thought after I raised it?

The Burketown clinic is NOT a "medical centre". "Medical practitoners"
> (often referred to as "doctors") have a special status in legislation and
> it would usually expected that only registered medical practitioners
> practise in a "medical centre".


I wasn't aware of that? I wonder if that's why a few of them around here
have changed their names over the last while from xxx Medical Centre to xxx
Medical Clinic?

"Amenity=clinic" would probably be the other tag I can suggest, even if the
> Burketown clinic might not satisfy wiki requirements for that tag either.


Until I just looked at the requirements, I wasn't aware of the +/- 10 staff
criteria! I've possibly mapped a few clinics that shouldn't be.

Perhaps the Australian Guidelines should permit the "hospital" tag where
> that is consistent with usage of the term by the local community.


Fair call - once again, comments / thoughts?

Thanks

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

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

[Martin Ždila]

Len pripomeniem, že aj na www.freemap.sk viete uploadovať fotky, pridať im
tagy a potom podľa nich filtrovať.

-- 
Ing. Martin Ždila 
OZ Freemap Slovakia
tel:+421-908-363-848
mailto:martin.zd...@freemap.sk
http://www.freemap.sk/
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-au] Are Health Centres, hospitals

[cleary]

The term "hospital" is subject to a lot of interpretation and is an emotionally 
laden issue in many rural communities.

Many of the "hospitals" mapped in NSW rural areas (and presumably in other 
states) do not satisfy the OSM definition of "hospital" and some would not 
satisfy the definition of "clinic" depending on whether the 10 staff (as 
specified in the OSM wiki) should be there at any one time or could be rostered 
one, two or three at a time over the many hours of each working week. These 
health facilities are important to their communities and to visitors. If this 
is all the community has and they regard it as their "hospital" then I feel 
reluctant to take it away.

In the event of an accident or urgent illness, where would local residents or 
visitors go?  They will usually tell you to go to the "hospital" (irrespective 
of its official title).  If one referred to a local map in an emergency, one 
would hope the nearest emergency treatment centre would be clearly identifiable 
on the map.

I reckon the locals would regard the Burketown facility as their hospital even 
if it is not so named and even if it does not satisfy OSM criteria. Further, 
the Queensland Health webpage states that the Burketown clinic provides limited 
"hospital services".  

The Burketown clinic is NOT a "medical centre". "Medical practitoners" (often 
referred to as "doctors") have a special status in legislation and it would 
usually expected that only registered medical practitioners practise in a 
"medical centre". Anyone other than a doctor would work strictly under the 
direction of medical practitioners in that location. That is not how hospitals 
or public health services operate. To my knowledge, "medical centres" in 
Australia are always operated by doctors in private practice. I am confident 
that would not be the case in Burketown.

"Amenity=clinic" would probably be the other tag I can suggest, even if the 
Burketown clinic might not satisfy wiki requirements for that tag either.  
Perhaps the Australian Guidelines should permit the "hospital" tag where that 
is consistent with usage of the term by the local community.   










On Fri, 4 Sep 2020, at 2:51 AM, Graeme Fitzpatrick wrote:
> Over the last few days, I've spotted a few places marked as hospitals 
> that aren't.
> 
> Locally, there were two Aged Care homes, then as I looked around 
> further, I spotted another Aged Care home, an Ambulance station in a 
> small country town & an SES station!
> 
> The Ambo station I could almost relate to, as that's where you go for 
> any medical emergency, but none of the others. Incidentally, there is 
> hopefully some progress on them being rendered? 
> https://github.com/gravitystorm/openstreetmap-carto/issues/3968
> 
> I did an Overpass search for Qld & found ~2100 "hospitals", which seems 
> like a lot?  https://overpass-turbo.eu/# (Don't know if that works or 
> not?), & checking at random, found more Ambo's, Doctor's surgeries & so 
> on also marked.
> 
> I did notice, though, a few of these: 
> https://www.health.qld.gov.au/services/northwest/nwest_burket_hc
> 
> Personally, I would call that a Medical Centre, not a Hospital?, while 
> this https://www.health.qld.gov.au/cq/hospitals/blackwater/services 
> with A & inpatients *is* a Hospital.
> 
> What do you all think?
> 
> Thanks
> 
> Graeme
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>

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

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

[Gad Jo]

Si vous voulez je peu m'en occuper à minima pour les bonnes pratique en France.

Le cas des giratoires à ne pas découper on le comprend mieux chez nous, le pays 
des rond point... On en a un nombre très important sans commune mesure avec 
celui qui est en deuxième position (info entendu sur le journal TV).
Il est probable que dans les autres pays que le cas se présente rarement et que 
personne ne s'y est intéressé.

Pour faire les modifications sur les pages EN faut il faire une demande de 
consensus via une page de discussions ? Quitte a passer sur l'hebdo osm pour 
stimuler les réponses
Il me faut juste quelques conseils et je me lance

Le September 3, 2020 2:38:45 PM UTC, Rpnpif via Talk-fr 
 a écrit :
>Le 01/09/2020 à 19:13, Georges Dutreix via Talk-fr a écrit :
>> Bonjour,
>>
>> J'ai souvent découpé des giratoires pour des lignes de bus : honte
>sur 
>> moi !
>> Promis, je ne le ferai plus ;-)
>>
>> Peut-être faudrait-il décrire les bonnes pratiques, pour les naïfs 
>> comme moi, dans des pages comme
>https://wiki.openstreetmap.org/wiki/FR:Bus
>> ou 
>>
>https://wiki.openstreetmap.org/wiki/FR:Relation:route#Les_itin.C3.A9raires_de_bus_et_les_ronds-points
>
>> ?
>>
>> Je ne maîtrise pas assez celles-ci pour m'amuser à modifier le wiki 
>> moi-même. Et il semblerait qu'il n'y ait pas consensus...
>> Peut-on écrire par ci par là que la bonne pratique en France est de, 
>> si possible, ne pas casser les rond points en plusieurs segments ?
>
>
>+1 ! Tout à fait d'accord.
>
>-- 
>Rpnpif

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

Re: [talk-au] Are Health Centres, hospitals

[Andrew Davidson]

On Fri, Sep 4, 2020 at 12:53 PM Graeme Fitzpatrick 
wrote:

>
> I did an Overpass search for Qld & found ~2100 "hospitals", which seems
> like a lot?  https://overpass-turbo.eu/# (Don't know if that works or
> not?), & checking at random, found more Ambo's, Doctor's surgeries & so on
> also marked.
>
>
I only get 202 for QLD https://overpass-turbo.eu/s/XGU. Are you searching
for something other than amenity=hospital and healthcare=hospital ?
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Are Health Centres, hospitals

[Michael James]

That list is for Queensland Health operated facilities not just hospitals so 
yes your right in that particular site would not be a hospital per se.

Not sure where you find a list of accredited hospitals but it is a thing as I 
live in a street with 2 facilities that are accredited as hospitals but only 
one calls itself a hospital.

Not sure QAS offers any walk up facilities anymore, the local one here has a 
phone out the front to call for help.

Michael


From: Graeme Fitzpatrick 
Sent: Friday, 4 September 2020 12:51 PM
To: OSM-Au 
Subject: [talk-au] Are Health Centres, hospitals

Over the last few days, I've spotted a few places marked as hospitals that 
aren't.

Locally, there were two Aged Care homes, then as I looked around further, I 
spotted another Aged Care home, an Ambulance station in a small country town & 
an SES station!

The Ambo station I could almost relate to, as that's where you go for any 
medical emergency, but none of the others. Incidentally, there is hopefully 
some progress on them being rendered? 
https://github.com/gravitystorm/openstreetmap-carto/issues/3968

I did an Overpass search for Qld & found ~2100 "hospitals", which seems like a 
lot?  https://overpass-turbo.eu/# (Don't know if 
that works or not?), & checking at random, found more Ambo's, Doctor's 
surgeries & so on also marked.

I did notice, though, a few of these: 
https://www.health.qld.gov.au/services/northwest/nwest_burket_hc

Personally, I would call that a Medical Centre, not a Hospital?, while this 
https://www.health.qld.gov.au/cq/hospitals/blackwater/services with A & 
inpatients is a Hospital.

What do you all think?

Thanks

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

[talk-au] Are Health Centres, hospitals

[Graeme Fitzpatrick]

Over the last few days, I've spotted a few places marked as hospitals that
aren't.

Locally, there were two Aged Care homes, then as I looked around further, I
spotted another Aged Care home, an Ambulance station in a small country
town & an SES station!

The Ambo station I could almost relate to, as that's where you go for any
medical emergency, but none of the others. Incidentally, there is hopefully
some progress on them being rendered?
https://github.com/gravitystorm/openstreetmap-carto/issues/3968

I did an Overpass search for Qld & found ~2100 "hospitals", which seems
like a lot?  https://overpass-turbo.eu/# (Don't know if that works or
not?), & checking at random, found more Ambo's, Doctor's surgeries & so on
also marked.

I did notice, though, a few of these:
https://www.health.qld.gov.au/services/northwest/nwest_burket_hc

Personally, I would call that a Medical Centre, not a Hospital?, while this
https://www.health.qld.gov.au/cq/hospitals/blackwater/services with A &
inpatients *is* a Hospital.

What do you all think?

Thanks

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

Re: [Talk-at] Auflassung OSM Austria Building Coverage

[scubbx]

Hallo, Thomas!

Das war ein wahnsinns Projekt! Von den vielen "man könnte doch ..." hast
du das einfach gemacht. :-)

Vor allem der Teil des Quellcodes, in dem du die Gebäudeinformation aus
den Basemap-Tiles extrahierst, finde ich interessant.
Das sieht wirklich sehr rechenintensiv aus.

Die Gebäudeumrisse in der Basemap sind ja auch nicht immer für voll zu
nehmen. Einige davon kommen aus dem Kataster, und die Gebäudedaten aus
diesem sind mit sehr großer Vorsicht zu genießen. 85% Abdeckung halte
ich daher für einen guten Wert!

Beste Grüße,
Markus (ScubbX)


Am 30.08.20 um 14:14 schrieb Thomas Konrad OSM:
> Liebe OSM-AT-Community,
>
> seit 2015 läuft ja auf meinem Server das Tool, mit dem man die
> OSM-AT-Gebäudeabdeckung im Vergleich zur Basemap gemeinde-, bezirks-
> und bundeslandweit auswerten kann [1]. Seither hat sich einiges getan
> — fast alle Gemeinden österreichweit sind laut dieser
> Berechnungsmethode auf über 85 % Abdeckung. Da ab diesem
> Prozentbereich aufgrund der Unschärfen in der Grundrissüberdeckung
> keine sinnvolle Unterscheidung mehr möglich ist, werde ich den Betrieb
> der Webseite mit 20. September 2020 einstellen.
>
> Mit ein Grund dafür ist, dass der Betrieb der Anwendung ziemlich
> rechenintensiv ist (es müssen dafür täglich mehrere Millionen
> PNG-Tiles Pixel für Pixel analysiert werden), und ich habe dafür extra
> einen Server angemietet, der nicht billig ist. Die Kosten und der
> Aufwand, die Anwendung und das Kartenmaterial aktuell zu halten (die
> Aktualisierung der Basemap-Tiles ist hier leider ein manueller
> Prozess) übersteigen mittlerweile den Wert des Webseiteninhaltens, der
> sich nicht mehr wesentlich ändert.
>
> Aber die Arbeit war alles andere als umsonst — ich denke das Werkzeug
> hat viele dazu motiviert, die Gebäudeabdeckung in Österreich zu
> verbessern, und die Statistik [2] zeigt, wie viel sich hier getan hat.
> Vielen vielen Dank an alle, die das zum Anlass genommen haben, die
> Datenlage in Österreich zu verbessern! Eure Arbeit ist extrem wertvoll.
>
> Falls jemand die Software weiterentwickeln und/oder selbst betreiben
> will, der Quellcode ist frei auf GitHub verfügbar [3] und steht unter
> der sehr liberalen MIT-Lizenz.
>
> Danke und schöne Grüße,
> Thomas
>
> [1] https://osm-austria-building-coverage.thomaskonrad.at/
> [2] 
> https://osm-austria-building-coverage.thomaskonrad.at/coverage-chart.svg?admin_level=1
> [3] https://github.com/thomaskonrad/osm-austria-building-coverage
>
> ___
> 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/SAMU] Projet du mois défibrillateurs

[Philippe Verdy]

Le jeu. 3 sept. 2020 à 20:35, Yves P.  a écrit :

>
> aucune donnée publique. pourtant ils invitent à déclarer les DAE par eux
>
>
> Comme Staying alive / AED-Map ;)
>
> A la différence près que ces données sont publiées dans data.gouv.fr
> 
>
>
> SauvLife ne traite que les agences publiques, il n'a forcément pas tous
> les DAE concernés par ces déclarations).
>
> D'où tiens-tu cette information ?
>

Leur page d'accueil qui ne mentionne que des structures
médico-hospitalières publiques. Les autres sont juste des "partenaires".
Rien n'est indiqué sur les procédures de controle, et leur formulaire en
ligne n'est pas fait pour tout le monde avec ce qui est demandé et il
manque de pas mal de précisions: en gros juste le nom de l'organisme,
l'adresse de l'établissement (adresse fiscale ou de gestion) et les noms,
numéros ou adresses de contacts, le reste c'est du champ libre facultatif.
Rien n'est demandé vraiment sur la localisation exacte, l'accessibilité
réelle n'est pas demandée, rien non plus sur l'entretien. Même pas la
possibilité de se géolocaliser précisément sur une carte. Rien non plus
pour identifier le matériel (et éviter les doublons possibles selon qui va
utilsier le formulaire, et pas grand chose pour justifier l'identité du
déclarant: pas de quoi justifier plus tard ses obligations légales, et rien
pour que les autres employés puissent contrôler que cela a bien été déclaré
et si les restrictions d'accès imposées ou les limites d'entretien sont
respectées ou valides).
En gros cela ne crée ni plus ni moins qu'un agenda privé (mais pas grand
chose n'est dit sur ce qu'ils vont faire réllement de ces données et quel
droit d'accès ou de rectification sera possible, visiblement ce n'est pas
au point pour le RGPD avec les professions libérales).
Efin SAUV met une licence exclusive par défaut à tout son site et se
réserve le droit d'utiliser comme il veut les données collectées. Il n'est
pas conforme au RGPD concernant les visiteurs du site. Que dire aussi de
leur appli mobile: j'ai plus confiance en celle de la Croix-Rouge française
(bien plus connue aussi et plus complète, téléchargée par près de 5
millions de français, et c'est déjà pas si mal même si cette appli peut
être améliorée en terme d'accessibilité).

Que dire aussi de l'appli mobile Sop-Coviv du gouvernement: c'est déjà dur
à trouver, elle est franchement pas simple à installer (quoi qu'en disent
Googgle et Apple sur leurs stores), elle bouffe énormément de batterie (il
faut la désactiver si on veut recharger son téléphone) et elle n'apporte
presque aucun service: quitte à la laisser allumée, autant que ce soit
intégré dans l'appli de la Croix-Rouge (avec les mêmes APIs développées en
commun par Google et Apple, une API sensée être ouverte et que ces OS
devraient optimiser un peu mieux: l'appli ou l'API commune bouffe plus
qu'une connexion Bluetooth à son autoradio ou à une oreillette sans fil)

>
> N'importe qui peut déclarer un DAE :
> https://sauvlife.fr/declarer-un-defibrillateur/
>
> Après, qui vérifie et comment, mystère ?
>
>
> Philips fabrique aussi des DAE et vend une prestation pour référencer des
> DAE à la place des exploitants :
> https://dae.philips.fr/services-philips/localisation-defibrillateur
>
> "La prestation de « Géolocalisation d’un DAE » de Philips permet de
> collecter et d’enregistrer les données d’un défibrillateur dans 1 ou 2
> bases de données que vous choisissez, pour votre compte."
>
> Ils parlent de GeoDAE, de AEDMAP, de Sauv life ?
>
>
> En quoi aussi l'asso SauvLife aurait plus d'habilitations qu'OSM
>
>
>
>- Elle est dirigée par des médecins urgentistes ;)
>- Elle a un partenariat avec des SAMU.
>- N'importe qui peut modifier les données OSM, ça ne doit pas rassurer
>:D
>
>
>
> GeoDAE peut-il alors accepter les contributions d'OSM si on arrive à les
> qualifier
>
>
> Bonne question.
>
>
> Même s'ils remontent des infos à GeoDAE;
>
>
> Est-ce que c'est bien le cas ?
>
>
> __
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] La gestion des poteaux

[Philippe Verdy]

Le jeu. 3 sept. 2020 à 20:48, Francois Gouget  a écrit :

> On Thu, 3 Sep 2020, Philippe Verdy wrote:
>
> > la puissance transportée,
>
> La puissance transportée dépend de si le sèche-cheveux est allumé ou
> éteint.
>

Je voulait dire en capacité maximale (donc "transportable" plus que
"transportée" à un instant T: ca dépend des câbles, des isolateurs, du
champ électrique (tension/écartement et un facteur dépendant du nombre de
phases ou du différentiel avec la terre ou des écarts de puissance acceptés
entre les phases, et les tolérances sur le déphasage dépendant de la
puissance sur de chaque circuit et des points de consommation), de la
capacité aussi des transformateurs (et leur refroidissement) et ce qui est
toléré par les coupe-circuits près des postes de transformation et de
distribution ou des transfos relais (même sans changement de tension).
C'est à cause de ça que les porteurs sont aussi différents en taille et en
hauteur.

>
> > le nombre de câbles,
>
> Le nombre de cables se voit sur les photos aériennes.
>

Pas toujours il y a plein de petites lignes même si on est capable de le
dire. Difficile de dire souvent s'il y a 3 ou 5 câbles ou plus. ou même
s'il y en a plus d'un seul. Ca dépend beaucoup du fond (y compris la
saison), et de la précision et l'éclairage des photos. On peut parfois
devenir sur certains poteaux ou segments, mais ça se complique vite
quand il y a des ramifications (et on ne voit pas bien toutes les
ramifications du réseau mineur). Et de toute façon pas moyen de deviner les
tensions transportées et le mode (nombre de phases ou continu à certains
endroits)

Les transfos sont également pas faciles à voir (et pas toujours montés en
haut des poteaux, j'en ai vu à plusieurs centaines de mètres du dernier
poteau quand la ligne passe sous-terre et ce transfo est souvent caché dans
la végétation ou dans des constructions agricoles ou industrielles ou
parfois enterré sous une trappe difficile à voir (ou dans une armoire
difficile à distinguer d'une armoire télécoms; ces transfos de distribution
ne sont souvent pas bien grands et sur l'imagerie aérienne on ne peut même
pas savoir que c'en est ou si c'est un engin agricole, un puits.)

Pour le gaz c'est plus facile car le chemin est marqué par des gros points
jaunes ou chapiteaux jaunes sur un poteau très visibles presque partout et
presque toujours en bordure de chemin ou en limite de parcelle sur une aire
dégagée.

Sinon si j'ai des doutes, tant pis je ne relie pas: ces segments
déconnectés seront détectés et joints plus tard quand on aura plus de
données, mais ça indique justement le lieu où on a un manque d'information
et ça guide ensuite l'exploration au sol pus tard en fixant des objectifs à
voir auxquels on ne penserait pas.


> > la hauteur des poteaux ou leur nature (bois ou métallique)
>
> Ou béton. Ça on peut le voir sur les photos Mapillary / OpenStreetCam
> quand il y en a. Je me demande si c'est une caractéristique régionale ou
> si c'est une question d'époque.
>

 Oui aussi. Les poteaux en bois sont sans doute plus courants dans les
régions forestières. L'alu coûte cher et pas forcément non plus plus
résistant dans les régions venteuses ou pas accepté dans certains
secteurs protégés (en plus les poteaux en alu doivent être "chapeautés"
mais les chapeaux en plastique ne résistent souvent pas longtemp).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-at] Fwd: What's new @ GeoDaten Burgenland

[Stefan Tauner via Talk-at]

On Thu, 3 Sep 2020 22:01:07 +0200
Friedrich Volkmann  wrote:

> https://geodaten.bgld.gv.at/index.php?id=172=web
> 
> Irgendwas dabei, was wir für OSM verwenden können?
> Mag jemand einen WMS aufsetzen mit Hangneigungskarte oder mit Schummerung 
> mit verschiedenen Beleuchtungsrichtungen?

Was mir bisher beim Mappen am meisten geholfen hat, sind digitale
Geländemodelle mit einer Auflösung, die das Auffinden von zumindest
Forstraßen wenn nicht sogar breiteren Wegen in dichten Wäldern
ermöglicht. Ich hab erst heute einen solchen Weg, den ich durch das
tiroler DGM für sehr, sehr wahrscheinlich gehalten habe, in natura
verifizieren können. Forststraßen sind dort überdeutlich sichtbar und
für das geübte Auge auch leicht von Wassergräben, Bächen und ähnlichem
unterscheidbar. Apropos... von Gewässern erodierte Gräben i.e.
Wasserverläufe sind dadurch auch recht gut - oft besser als mit
optischen Luftbildern - nachverfolgbar.

Lt. dem Text wäre das wohl vorhanden und nutzbar...?
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

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

[Talk-at] Fwd: What's new @ GeoDaten Burgenland

[Friedrich Volkmann]

https://geodaten.bgld.gv.at/index.php?id=172=web

Irgendwas dabei, was wir für OSM verwenden können?
Mag jemand einen WMS aufsetzen mit Hangneigungskarte oder mit Schummerung 
mit verschiedenen Beleuchtungsrichtungen?


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

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

[Lukas Gebauer via talk-cz]

> Jinak na osmap.cz je pro chybejici rozcestniky potreba zapnout vrstvu Kontroly
> OsmHiCheck (v sekci Specialni)

Ano, myslim, ze prave tahle data to zobrazuje.

Nahrane fotky nezobrazuje, protoze ucelem neni nahradit Fody, ale 
spis napovedet, kde pri lovu geocache pomoci odstranit nejaky ten  
problem.

Nicmene cela ta Geogeti mapa je modularni, a tak neni problem si 
pomoci dalsich modulu pridat prakticky cokoliv. Treba i vrstvu s 
fotkami. Otazka je, u ceho to ma smysl dublovat funkci osm.cz.

> > > Tak třeba začnou přibývat rozcestníky od geocaching komunity ;)

Ve skutecnosti mezi sebou mnoho geocacheru davno mame, a stoji za 
nimi mnoho fotek. Ostatne, prave proto prisli s myslenkou ty 
rozcestniky ukazat na jedne mape s geocache. Takze novych asi moc 
nepribude, ale tem stavajicim to usnadni praci.



-- 
Lukas Gebauer.

http://synapse.ararat.cz/ - Ararat Synapse - TCP/IP Lib.
https://www.geoget.cz/ - Geocaching solution


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

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

[Martin Koppenhoefer]

sent from a phone

> On 3. Sep 2020, at 20:59, Cascafico Giovanni  wrote:
> 
> dal dataset luglio 2020:
> Iscritto in elenco 3561
> Rimosso dall`elenco per abbattimento 17
> Rimosso dall`elenco per morte naturale 39
> Rimosso dall`elenco per perdita di requisiti 9


un’altra cosa: ci sono anche nuovi alberi? Se li perdiamo con questo ritmo sono 
finiti fra 54 anni.

Ciao Martin 
___
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 3. Sep 2020, at 20:59, Cascafico Giovanni  wrote:
> 
> Rimosso dall`elenco per perdita di requisiti 9



questo mi interessa, ne hai degli informazioni in più quando accade?


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]

Il 02/09/20, Alessandro Sarretta ha scritto:

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

dal dataset luglio 2020:
Iscritto in elenco 3561
Rimosso dall`elenco per abbattimento 17
Rimosso dall`elenco per morte naturale 39
Rimosso dall`elenco per perdita di requisiti 9

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

Re: [OSM-talk-fr] La gestion des poteaux

[Francois Gouget]

On Thu, 3 Sep 2020, Philippe Verdy wrote:

> Note: avec l'imagerie haute résolution on commence à bien voir les poteaux
> et lignes électriques mineures (notamment en milieu rural ou périurbain à
> travers les champs pour relier les hameaux ou certaines zones
> industrielles).

Je confirme. En campagne on les voit très bien et on peut cartographier 
au moins 80% des lignes. Là où il y a des difficultés les photos 
Mapillary / OpenStreetCam peuvent dépanner.

https://www.openstreetmap.org/edit?node=1676592637#map=19/45.88764/-0.00136

En ville les lignes sont enterrées alors forcément c'est plus difficile 
de les repérer sur les vues aériennes.


> Que fait-on de ces lignes mineures ? on continue à les cartographier (comme
> on peut) ou on attend des données ouvertes d'un exploitant pour avoir
> d'autres infos comme les tensions, 

La plupart du temps on trouve un transformateur Enedis à un bout de la 
ligne ce qui permet par continuité de qualifier tout ce qui y est 
connecté.

D'ailleurs Osmose constitue un bon point de départ. Il sufit de choisir 
un transformateur manquant en rase campagne. 
https://osmose.openstreetmap.fr/fr/map/?#zoom=16=45.77269=-0.54326=8280

Il se trouvera en haut d'un poteau qu'on pourra ajouter. Ensuite si 
l'image est bonne et que le fond s'y prête on sait tout de suite dans 
quelle direction chercher le suivant. Sinon il faut chercher un peu, 
s'aider des trouées dans les forêt, etc. Ensuite il n'y a plus qu'à 
dérouler la pelote de laine. Quand elle s'éfiloche on recommence avec un 
autre transformateur pas loin. Et à la fin, miracle, on se retrouve avec 
un plat de spaghetti !

https://openinframap.org/#11.46/45.9534/0.7541


> la puissance transportée,

La puissance transportée dépend de si le sèche-cheveux est allumé ou 
éteint.

> le nombre de câbles,

Le nombre de cables se voit sur les photos aériennes.

> la hauteur des poteaux ou leur nature (bois ou métallique)

Ou béton. Ça on peut le voir sur les photos Mapillary / OpenStreetCam 
quand il y en a. Je me demande si c'est une caractéristique régionale ou 
si c'est une question d'époque.

Sur les photos aériennes on repèrera aussi les power=portal.


-- 
Francois Gouget   http://fgouget.free.fr/
question = ( to ) ? be : ! be;
  -- Wm. Shakespeare___
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

[Yves P.]

> aucune donnée publique. pourtant ils invitent à déclarer les DAE par eux

Comme Staying alive / AED-Map ;)

A la différence près que ces données sont publiées dans data.gouv.fr 



> SauvLife ne traite que les agences publiques, il n'a forcément pas tous les 
> DAE concernés par ces déclarations).

D'où tiens-tu cette information ?

N'importe qui peut déclarer un DAE : 
https://sauvlife.fr/declarer-un-defibrillateur/

Après, qui vérifie et comment, mystère ?


Philips fabrique aussi des DAE et vend une prestation pour référencer des DAE à 
la place des exploitants :
https://dae.philips.fr/services-philips/localisation-defibrillateur

"La prestation de « Géolocalisation d’un DAE » de Philips permet de collecter 
et d’enregistrer les données d’un défibrillateur dans 1 ou 2 bases de données 
que vous choisissez, pour votre compte."

Ils parlent de GeoDAE, de AEDMAP, de Sauv life ?


> En quoi aussi l'asso SauvLife aurait plus d'habilitations qu'OSM

Elle est dirigée par des médecins urgentistes ;)
Elle a un partenariat avec des SAMU.
N'importe qui peut modifier les données OSM, ça ne doit pas rassurer :D


> GeoDAE peut-il alors accepter les contributions d'OSM si on arrive à les 
> qualifier

Bonne question.


> Même s'ils remontent des infos à GeoDAE;

Est-ce que c'est bien le cas ?


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

[Philippe Verdy]

Oui on a une carte avec juste les départements des SAMU concernés pour
l'instant (et les quelques autres assos partenaires). Ils annoncent que
cela concernera bientôt tous les départements, mais aucune donnée publique.
pourtant ils invitent à déclarer les DAE par eux (en espérant que ça
remonte plus tard dans le geoDAE publié, mais comme SauvLife ne traite que
les agences publiques, il n'a forcément pas tous les DAE concernés par ces
déclarations).

Donc cela fait un tiers de plus (un autre asso qui agit comme
intermédiaire), mais ça ajoute aussi du retard (et de possibles erreurs
d'intégration). En quoi aussi l'asso SauvLife aurait plus d'habilitations
qu'OSM, le fait que ses membres ne sont que des organisations publiques ou
reconnues ? GeoDAE peut-il alors accepter les contributions d'OSM si on
arrive à les qualifier mieux que ces déclarations approximatives qu'on voit
dans le GeoDAE (et qui sans doute sont passées dans les mains de
SauvLife qui na pas du faire grand chose de plus pour les qualifier si ce
n'est fournir la plateforme technique et un espace d'échange) ?

Même s'ils remontent des infos à GeoDAE; je ne vois pas ce qui les empêche
de publier les données de déclarations obligatoires qu'ils collectent, ces
données étant normalement destinées à être publiques.


Le jeu. 3 sept. 2020 à 20:03, Yves P.  a écrit :

> Et ça n'a pas manqué : mon SAMU contacté au téléphone aujourd'hui m'a
> *immédiatement* renvoyé à Sav'Life :(
>
> https://sauvlife.fr/carte-du-deploiement/
>
> J'ai tout de même envoyé un mail de prise de contact.
>
> Merci de nous éclairer si tu as une réponse :)
>
> __
> Yves
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Yves P.]

> Et ça n'a pas manqué : mon SAMU contacté au téléphone aujourd'hui m'a 
> *immédiatement* renvoyé à Sav'Life :(
https://sauvlife.fr/carte-du-deploiement/

> J'ai tout de même envoyé un mail de prise de contact.
Merci de nous éclairer si tu as une réponse :)

__
Yves



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

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

[nine-osm . org-lists]

Hallo,

als Alpinist und OSM Mapper halte ich die Keys
- sac_scale [1] und
- trail_visibility [2]
für relevante Information zum mappen alpiner Pfade.

Allgemein können Karten potentiell immer falsch sein, man denke nur an 
plötzliche Änderungen durch Naturereignisse wie Muren, Steinschlag, 
Gletscherschmelze, etc.


Allgemein und bei den angesprochenen Fällen ist Eigenverantwortliches 
und vorausschauendes Handeln ist daher im Gelände immer höchstes Gebot.


Wenn es in der Realität (also nicht in der App) zu schwer wird und der 
Pfad nicht zu finden ist dann soll man besser umdrehen. ¯\_(ツ)_/¯


LG
Erwin


Links
[1] https://wiki.openstreetmap.org/wiki/Key:sac_scale#Values
[2] https://wiki.openstreetmap.org/wiki/Key:trail_visibility


On 9/3/20 3:05 PM, Johann Haag wrote:
Mir wäre Neu, dass es im Internet Bergrouten gibt, Bergrouten gibt es am 
Berg.
In OpenStreetMap kann man sich unter osm.org  
öffentliche GPS-Tracks einblenden. Ich finde derlei Schwarmintelligenz 
zum erkennen von Hauptrouten jedenfalls sehr nützlich, praktisch und 
auch verlässlich.

Auch offizielle Karten können irren, https://youtu.be/oYdmqf_P8DM?t=165

Grüße Johann

Am Do., 27. Aug. 2020 um 12:39 Uhr schrieb PPete >:


Gestern gab es in ORF-Bundesland heute OÖ einen Bericht (mit jenem
Titel) über einige kürzlich stattgefundene Bergrettungseinsätze, die
teilweise mit falsch eingetragenen Pfaden in der OSM oder der
Verwendung von ungeeigneten Karten zum Bergwandern zu tun haben. Zu
einem der Fälle gabs kürzlich auch einen Bericht in den OÖN. Siehe:

https://ooe.orf.at/stories/3064030/

https://www.nachrichten.at/oberoesterreich/abkuerzung-per-routenapp-aufwendige-rettungsaktion-im-toten-gebirge;art4,3286408

Beim Fall am Mittagkogel geht's vermutlich um die Strecke vom
Rinnerkogel (2012 m) zum Mittagkogel (1823 m) und in weiterer Folge
über die Grünbergalm runter zum Offensee:
https://www.openstreetmap.org/#map=15/47.7238/13.8372

Ich muss sagen, ich kenne den Weg und Gegebenheiten vorort nicht,
aber es hört sich für mich an dass sich der Mapper damals Gedanken
darüber gemacht hat und Schwierigkeit und Sichtbarkeit so bewertet,
dass er als schlecht sichtbarer, sehr schwieriger alpiner Steig
eingetragen ist.
Der Pfad hat "sac_scale=demanding_alpine_hiking" und
"trail_visibility=horrible"

Nun das große Problem aus meiner Sicht: Es gibt nur sehr wenige
Karte die diese OSM-Skalen auch darstellen und man schon bei der
Planung oder später unterwegs sieht, was für ein Pfad einem in etwa
erwartet. Wenn ihr euch den obigen Openstreetmap-Link anschaut sehen
darauf alle Pfade gleich aus, ein rot gepunktete Linie. Also ein
kaum sichtbarer hochalpiner Steig genauso wie ein einfaches, bestens
markiertes Wanderwegerl durch flachen Wald.

Vorbildlich wird dies soweit mir bekannt nur z.b. auf
OpenAndroMaps-Karten dargestellt (die ich selber schon lange als
Standarkarte am Handy verwende) wo Pfade nach Farben
(=Schwierigkeit) und Strichlängen (=Sichtbarkeit) zu unterschieden
sind. Der angesprochene Weg ist darin schwarz (sehr schwer) und
punktiert (sehr schlechte sichtbarkeit) dargestellt.

Letztendlich bleibt die Eigenverantwortlichkeit das man sich vor so
einer alpinen Tour über geeignetes Kartenmaterial informiert. Und
zweitens muss man sich ev. als Kartenanbieter auch fragen ob ich
wirklich jedes hochalpine Steiglein aus den OSM-Daten in meine Karte
einzeichne, wenn diese darin nicht von gewöhnlichen, gefahrlosen
Wanderwegerl unterscheidbar sind.

Dann wird vom Bergrettungsmann im ORF-Bericht noch ein Steig
nördlich des Krippensteins erwähnt bzw. am PC gezeigt, der angeblich
gar nicht vorhanden ist und auch schon zu Einsätzen geführt hat. Was
damit machen? Ihn löschen und der Bergrettung über die Löschung
Bescheid geben? Oder vorher mit ihr Kontakt aufnehmen und fragen
welche Abschnitte genau zu löschen sind? Er hat gesagt er hätte zum
"Kartenanbieter" Kontakt aufgenommen, aber scheinbar ohne "Erfolg",
der Pfad dürfte immer noch vorhanden sein.
___
Talk-at mailing list
Talk-at@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-at



--
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at 

___
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] uMap, SILL et Wikidata

[Philippe Verdy]

Note: je n'ai pas indiqué la compatibilité avec les OS supportés (OK il y a
Linux, mais pour le détail des distribs ou formats de package, il vaut
mieux que ce soit les auteurs et mainteneurs qui précisent ça; je ne sais
pas si ça a été testé/utilisé/adapté à d'autres OS car c'est un logiciel
serveur, indépendant des OS des clients web; il peut aussi y avoir des
clients spécifiques pour certains OS mobiles, développés séparément ou
maintenus par les installateurs d'autres instances que l'instance française
"par défaut")

Le jeu. 3 sept. 2020 à 19:40, Philippe Verdy  a écrit :

> Pour Wikidata, j'ai ajouté quelques propriétés (y compris  en français et
> anglais) avec les liens les plus utiles.
>
> https://www.wikidata.org/wiki/Q28502462
>
> Il n'y a pas de page Wikipédia en français je pense, je n'ai vu que
> l'espagnol. Mais les liens sur le wiki OSM (français et anglais) y sont (en
> tant que "documentation"). J'ai ajouté les langages de programmation, les
> autres outils essentiels dont uMap dépend, les infos de licence et d'auteur
> plus complètes
>
> Le mar. 1 sept. 2020 à 08:55, Cédric Frayssinet  a
> écrit :
>
>> Bonjour à tous,
>>
>> Cet été, j'ai découvert que uMap avait été introduit au SILL qui est une
>> référence pour les collectivités (mais pas que) :
>> https://fr.wikipedia.org/wiki/Socle_interminist%C3%A9riel_de_logiciels_libres
>>
>> Et j'ai fait remarqué à Bastien Gerry que la fiche était très
>> approximative : https://sill.etalab.gouv.fr/fr/software?id=150
>>
>> Il m'a donc répondu qu'il fallait compléter la fiche wikidata comme celle
>> de Gimp : https://www.wikidata.org/wiki/Q8038. Cela tombe bien car il
>> semblerait qu'elle ait été amorcée en espagnol :
>> https://www.wikidata.org/wiki/Q28502462
>>
>> Le code source du SILL est également ici :
>> https://github.com/DISIC/sill/blob/master/2020/sill-2020.csv
>>
>> J'appelle donc à l'aide. Si certains d'entre vous sont à l'aise avec
>> GitHub et WikiData, je pense que ce serait bienvenue d'améliorer cette
>> fiche :)
>>
>> Merci à la communauté,
>>
>> Cédric
>> --
>>
>> Sur Mastodon : @bristow...@framapiaf.org
>> 
>>
>> [image: Promouvoir et soutenir le logiciel libre] 
>> ___
>> 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] uMap, SILL et Wikidata

[Philippe Verdy]

Pour Wikidata, j'ai ajouté quelques propriétés (y compris  en français et
anglais) avec les liens les plus utiles.

https://www.wikidata.org/wiki/Q28502462

Il n'y a pas de page Wikipédia en français je pense, je n'ai vu que
l'espagnol. Mais les liens sur le wiki OSM (français et anglais) y sont (en
tant que "documentation"). J'ai ajouté les langages de programmation, les
autres outils essentiels dont uMap dépend, les infos de licence et d'auteur
plus complètes

Le mar. 1 sept. 2020 à 08:55, Cédric Frayssinet  a
écrit :

> Bonjour à tous,
>
> Cet été, j'ai découvert que uMap avait été introduit au SILL qui est une
> référence pour les collectivités (mais pas que) :
> https://fr.wikipedia.org/wiki/Socle_interminist%C3%A9riel_de_logiciels_libres
>
> Et j'ai fait remarqué à Bastien Gerry que la fiche était très
> approximative : https://sill.etalab.gouv.fr/fr/software?id=150
>
> Il m'a donc répondu qu'il fallait compléter la fiche wikidata comme celle
> de Gimp : https://www.wikidata.org/wiki/Q8038. Cela tombe bien car il
> semblerait qu'elle ait été amorcée en espagnol :
> https://www.wikidata.org/wiki/Q28502462
>
> Le code source du SILL est également ici :
> https://github.com/DISIC/sill/blob/master/2020/sill-2020.csv
>
> J'appelle donc à l'aide. Si certains d'entre vous sont à l'aise avec
> GitHub et WikiData, je pense que ce serait bienvenue d'améliorer cette
> fiche :)
>
> Merci à la communauté,
>
> Cédric
> --
>
> Sur Mastodon : @bristow...@framapiaf.org
> 
>
> [image: Promouvoir et soutenir le logiciel libre] 
> ___
> 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-de] Maß für die Genauigkeit von Eigenbau-GPS-Geräten?

[Heinz-Jürgen Oertel]

Am Mittwoch, 2. September 2020, 21:53:34 CEST schrieb Markus via Talk-de:
> oder in GitHub

https://www.heise.de/tipps-tricks/GitHub-vs-GitLab-4597154.html

> und natürlich im OSM-Wiki 

auf alle Fälle da auch.

> 
> Gruss, Markus

 Heinz



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

Re: [Talk-it] Google trekker

[Cascafico Giovanni]

Oltretutto oggi le 360° pesano pochi grammi... il mio pensier va a quei
poveri camminatori che nel 2014 si son fatti i sentieri con quell'arnese
google da 40kg

Il gio 3 set 2020, 17:56 Volker Schmidt  ha scritto:

> Penso che Mapillary ha un vantaggio su percorsi ciclabili e pedonali.
> E' anche adesso disponibile senza limiti con licenza aperta addirittura
> per uso commerciale.
> Sull'aspetto tecnico il loro visualizzatore ê migliore di quello di
> Streetview.
> Se fate le foto con una camera 360 con GPS incorporato (come Garmin VIRB
> 360), il risultato è bello.
> Guardate le foto 360gradi dell'utente  giubar
> 
> .
>
> Volker
>
> On Thu, 3 Sep 2020, 12:28 Alessio Piccioli, 
> wrote:
>
>> Ciao a tutti,
>>
>>   non ho più seguito in dettaglio il discorso di Google ma il CAI
>> Nazionale sta con OSM!!! A breve rinnoveremo la convenzione e in questi
>> anni sono stati inseriti un sacco di percorsi in tutta Italia siamo a
>> 70.000 Km se non erro.
>>
>> Detto questo l'idea dello StreetView sui sentieri potrebbe essere un
>> qualcosa che attrae nei prossimi anni ci sarebbe Mapillary ma anche li
>> andiamo su terreno scivoloso in termini di usabilità (licenze e diritti)
>> del dato.
>>
>> E se ci inventassimo qualcosa che parte proprio dal popolo di OSM?
>> (magari mi sono perso un pochino e qualcosa già esiste?)
>>
>> Un saluto a tutte e tutti!!
>>
>> A.
>>
>> Il giorno mer 2 set 2020 alle ore 14:45 Manuel 
>> ha scritto:
>>
>>> 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 
>>> listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it
>>>
>>> ___
>>> Talk-it mailing 
>>> listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it
>>>
>>>
>>> ___
>>> Talk-it mailing list
>>> Talk-it@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-it
>>>
>>
>>
>> --
>> *Alessio Piccioli / *Amministratore unico
>> alessiopicci...@webmapp.it
>> www.webmapp.it
>> +39 328 53 60 803
>>
>>
>> P.Iva e CF 02266770508
>> CCIAA di Pisa n. 02266770508 del 01/08/2017
>> Capitale Sociale 10.000,00 €
>> ___
>> 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/SAMU] Projet du mois défibrillateurs

[Jacques Lavignotte]

Le 03/09/2020 à 18:08, Philippe Verdy a écrit :



Le mer. 2 sept. 2020 à 18:19, Jacques Lavignotte 



   (c'est le SAMU qui a et ça n'a pas été ouvert). 



Le SAMU n'étant pas forcément l'exploitant


Ce n'est pas tant qu'exploitant que mentionnais le SAMU mais comme 
partenaire de programmes utilisant les DAE.


Et ça n'a pas manqué : mon SAMU contacté au téléphone aujourd'hui m'a 
*immédiatement* renvoyé à Sav'Life :(

J'ai tout de même envoyé un mail de prise de contact.

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: [OSM-talk-fr] La gestion des poteaux

[Philippe Verdy]

Note: avec l'imagerie haute résolution on commence à bien voir les poteaux
et lignes électriques mineures (notamment en milieu rural ou périurbain à
travers les champs pour relier les hameaux ou certaines zones
industrielles).

Cependant beaucoup sont partielles et si on peut tracer ce qu'on voit il
est difficile de les qualifier et les relier au reste du réseau (d'autant
plus que souvent il y a des sections enterrées, et autour des
transformateurs pas facile à localiser et pas toujours très près du dernier
poteau). On ne voit pas ce réseau enterré (qui se développe surtout près
des habitations ou zones d'activités).

Il y a des kilomètres de ces lignes mineures un peu partout (et souvent en
milieu rural en plaine, où a eu lieu un très fort remembrement, c'est
presque le seul élément facilement repérable pour distinguer les champs et
chemins quand il n'y a pas de rivière ni de bois visibles et quand les
champs ou chemins agricoles ou petites routes se ressemblent tous)

Que fait-on de ces lignes mineures ? on continue à les cartographier (comme
on peut) ou on attend des données ouvertes d'un exploitant pour avoir
d'autres infos comme les tensions, la puissance transportée, le nombre
de câbles, la hauteur des poteaux ou leur nature (bois ou métallique) et
d'autres équipements annexes (par exemple pour éviter de laisser un sommet
ouvert sans chapeau où les oiseaux qui y tombent ou s'y réfugient ne
peuvent plus ressortir, ou encore si ces poteaux sont également porteurs
d'antennes ou portent aussi le transformateur ou le coupe-circuit) ou
encore s'ils sont toujours en service: ( on voit facilement les poteaux
mais mois facilement les câbles, car il reste des poteaux qui ne portent
plus rien mais sont restés en place et peuvent servir à autre chose, comme
support de clôtures par exemple) ?


Le jeu. 3 sept. 2020 à 18:04, François Lacombe 
a écrit :

> Salut à tous
>
> L'été a permis d'avancer certains projets pour pas mal de monde à ce que
> j'ai vu, y compris les projets du mois :p
>
> Suite aux développements de ces deux derniers mois, j'ai mis à disposition
> aujourd'hui un rendu pour montrer tous les poteaux électriques et telecom
> qu'on pouvait avoir dans OSM en France.
> www.gespot.fr
>
> Le sujet passionne en ce moment pour le déploiement de la fibre et
> plusieurs exploitants sont intéressés par ce que la contribution OSM a déjà
> produit.
> Exemple : http://gespot.fr/#14.84/46.04506/6.13543
>
> Un peu de documentation sur le sujet :
> https://common.infos-reseaux.com/files/telco/gespot.pdf
> @Zimmy : je vais essayer d'en reverser une partie dans les thématiques de
> GéOSM.
>
> Une proposition est en cours d'écriture pour finaliser l'approbation de
> man_made=utility_pole (tous les poteaux sauf électriques qui sont avec
> power=pole)
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_poles_proposal
> (pas encore traduite)
>
> C'est dores et déjà utile de compléter les power=pole du réseau de
> distribution avec operator=Enedis (dans les communes appropriées
> https://dataviz.agenceore.fr/distributeurs-energie-france/) ou d'ajouter
> les poteaux Orange de vos environs avec man_made=utility_pole +
> utility=telecom + operator=Orange
>
> A suivre pour la suite des événements, bonne soirée
>
> François
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-be] regional cycle routes in Brussels

[Stijn Rombauts via Talk-be]

 
And don't forget the superroutes. They're still lcn.

StijnRR

 On Thursday, September 3, 2020, 04:55:24 PM GMT+2, Jo  
wrote:  
 
 Yes, I'll look at those as well.
Jo
On Thu, Sep 3, 2020 at 1:00 PM Yves bxl-forever  
wrote:

Hello,

Thanks for this.

@Polyglot, I saw you updated numbered cycle routes (1 to 12).
The Brussels cycle route network also has 7 routes with letters.  I suppose we 
should apply the same change.
A small circle: https://www.openstreetmap.org/relation/237027
B middle circle: https://www.openstreetmap.org/relation/116569
C large circle: https://www.openstreetmap.org/relation/7418111 
CC: Canal/Kanaal: https://www.openstreetmap.org/relation/1119347
SZ Senne/Zenne valley: https://www.openstreetmap.org/relation/116611
MM Maalbeek valley: https://www.openstreetmap.org/relation/114235
PP (King’s Palace): https://www.openstreetmap.org/relation/2133184

Cheers.
Yves


On Thu, 3 Sep 2020 10:40:29 +0200
Jo  wrote:

> I had a look at them after downloading them using Overpass API and started
> making them continuous where they were 'broken'. So I went ahead and also
> converted them all to rcn.
> 
> Jo
> 
> On Thu, Sep 3, 2020 at 9:41 AM Jo  wrote:
> 
> > Hi Joost,
> >
> > In Flanders it depended more on topology than anything else. We used:
> >
> > lcn: for loops
> > rcn: for the numbered node networks, this logic was taken to rwn and rhn
> > later on
> > ncn: for long routes going from A to B (LFx) and then later for the Fxxx
> > cycle highways
> > icn: for European routes going from A to B
> >
> > In Brussels rcn doesn't seem to be used and those routes are topologically
> > more similar to the numbered routes system used in Flanders and Wallonia.
> >
> > I agree with you that it makes more sense to tag them as rcn.
> >
> > Jo
> >
> > On Thu, Sep 3, 2020 at 9:14 AM joost schouppe 
> > wrote:
> >  
> >> Hi,
> >>
> >> I was always a little confused that the regional cycle network is mapped
> >> as lcn in Brussels. Since this network is organized by Brussels-the-region,
> >> not Brussels-the-city, it seems logical that it should have the rcn tag. In
> >> fact, more so than the Flemish cycle node network, which is composed of
> >> several networks and almost by coincidence covers the region.
> >>
> >> This is also what we say in the wiki:
> >>
> >> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycle_Routes#Itin.C3.A9raires_Cyclables_R.C3.A9gionaux_-_Gewestelijke_Fietsroute
> >>
> >> But the example given there (https://www.openstreetmap.org/relation/9623
> >> I believe), is now mapped as an lcn.
> >>
> >> Looking at the edit history, it looks like there was a minor edit war
> >> about this, where user RoRay repeatedly changed it from rcn to lcn
> >> https://www.openstreetmap.org/changeset/8141976
> >> https://www.openstreetmap.org/changeset/12902663
> >> (RoRay is still mapping, still using the not-very helpful default
> >> changeset description "update")
> >>
> >> User BenoitL tried to change it back to rcn (with much better changeset
> >> comments :) - https://www.openstreetmap.org/changeset/12849599), but I
> >> guess he gave up. Polyglot later seems to have mapped most of the other
> >> routes; my guess is he just went with lcn because that's how the others
> >> were mapped.
> >>
> >> Apart from the network not showing up when it should on some maps, it
> >> doesn't really matter much. However, bxl-forever is now mapping -actual-
> >> lcn routes in the Brussels region, operated by Anderlecht municipality.
> >> Example: https://www.openstreetmap.org/relation/11544325
> >> Putting both types of routes in the same level is just wrong IMHO.
> >>
> >> Can anyone provide some more context? Based on my own research, I'd
> >> suggest we simply retag all the regional operated routes from lcn to rcn.
> >>
> >> Best,
> >> Joost Schouppe
> >> ___
> >> Talk-be mailing list
> >> Talk-be@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-be
> >>  
> >  

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

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

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

[Philippe Verdy]

Le mer. 2 sept. 2020 à 18:19, 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).


Le SAMU n'étant pas forcément l'exploitant à qui on impose l'installation
et la déclaration, je ne pense pas que la loi prévois l'obligation des SAMU
à déclarer leurs propres données qui ne sont éventuellement que des
constatations sur le terrain, mais pas nécessairement suivies (par exemple
en cas de changement d'exploitant ou d'usage des lieux, il peut ne plus y
en avoir puisq'uil n'y a plus d'obligation et que l'obligation entraine un
coût de gestion, notamment signer un nouveau contrat d'entretien)

Dans ce cas, le SAMU est dans la même situation qu'OSM lui-même: c'est une
base indicative, pas soumise aux mêmes contraintes légales (notamment en
terme de délai de publication, ou de remise à jour imposée).

Je me demande d'ailleurs quel est le régime légal des mises à jour (quand
elles sont demandées et avec quels délais, ou s'il y a aussi obligation de
déclaration rapide des appareils hors services et des délais imposés pour
les remises en état et les garanties que les exploitants doivent pouvoir
attendre des sociétés de maintenance, et à quel rythme ce sera contrôlé)

Je suppose que ça peut se limiter à une déclaration au mieux tous les ans
masi que GeoDAE a des infos qui déjà date de plusieurs années et plus du
tout à jour, ou partielles: un seule DAE déclaré par l'exploitant même s'il
y en a plusieurs sur des sites un peu importants ou des exploitants sur
plusieurs sites d'une même ville qui peuvent être éloignés de
plusieurs kilomètres en tenant compte aussi des accès publics s'il faut
faire un grand détour autour du site, mais avec un seul siège: pour ceux
qui sont habilités à entrer à l'intérieur, ces sites peuvent sembler très
proches et n'être déclarés qu'une seule fois, leur accès ne se faisant pas
par ces grands détours).

Les textes à ce sujet sont encore récents, le système commence à peine à se
déployer, il y a encore plein d'expérimetnation, on est juste ne phase de
montée en charge et la réglementation va s'affiner en fonction des
résultats ou expérimentations ou en cas d'abus trop faciles ou trop de
défaillances dans le fonctionnemetn ou d'inefficacité (si au final cela ne
dépend toujours que de l'équipement des véhicules et personnels de secours
d'urgence et de leurs délais d'intervention).

D'ailleurs on voit les limites des déclarations actuelles: elles sont peu
précises et ce n'est pas évident que cela aide réellement le public visé,
c'est à dire presque tout le monde (même un grand nombre de mineurs et
aussi les touristes et migrants qui n'ont pas forcément à comprendre notre
langue et notre réglementation) et pas juste des spécialistes ou des
professionnels de la sécurité ou des cartographes expérimentés.

En France quand même ce public a trois types de contacts :
- (1) la police/gendarmerie (et maintenant aussi les agents de sécurité
privés depuis la loi récente de "sécurité globale" votée cette année
transférant pas mal de fonction de la police publique vers le
secteur privé, notamment les sociétés de vigiles ou les agents internes ou
externes missionnés par les sociétés de transport),
- (2) la sécurité civile/les pompiers/les SDIS,
- (3) le SAMU/15 et les services hospitaliers (qui sont les plus sollicités)

Et une unification surtout autour du 112 (conformément aux règles
européennes): peut-être qu'il faut coordonner aussi ces 3 secteurs autour
de ceux qui s'occupe en France de la gestion du 112 européen.
GeoDAE restera un test à intégrer dans une politique plus large et la
législation devra revoir les obligations propres à chacun des 3 secteurs
(plus le dernier secteur autres exploitants soumis à exploitation, dont les
grosses entreprises au delà d'un seuil d'employés, ou celles installées sur
des sites privés de taille importante, celles déjà déclarées comme
dangereuses comme les sites industriels, les installations de production
électrique, les grand chantiers de construction ou de démolition, la
restauration, les hôtels, les parcs de loisir, les écoles, universités,
salles de sport publiques et privées, gares et hubs de transport, les
salles de spectacle, les événements temporaires comme les foires ou les
autres rassemblements, et pourquoi pas même les organisateurs de grandes
manifestations à déclaration obligatoire, qu'elles soient festives,
culturelles, sportives, syndicales, politiques, hors des murs
habituellement dédiés à ces usages et qui sont déjà soumises à des
obligations de sécurité et d'assistance aux personnes).

Et puis il y a l'équipement mobile en plus des 

[OSM-talk-fr] La gestion des poteaux

[François Lacombe]

Salut à tous

L'été a permis d'avancer certains projets pour pas mal de monde à ce que
j'ai vu, y compris les projets du mois :p

Suite aux développements de ces deux derniers mois, j'ai mis à disposition
aujourd'hui un rendu pour montrer tous les poteaux électriques et telecom
qu'on pouvait avoir dans OSM en France.
www.gespot.fr

Le sujet passionne en ce moment pour le déploiement de la fibre et
plusieurs exploitants sont intéressés par ce que la contribution OSM a déjà
produit.
Exemple : http://gespot.fr/#14.84/46.04506/6.13543

Un peu de documentation sur le sujet :
https://common.infos-reseaux.com/files/telco/gespot.pdf
@Zimmy : je vais essayer d'en reverser une partie dans les thématiques de
GéOSM.

Une proposition est en cours d'écriture pour finaliser l'approbation de
man_made=utility_pole (tous les poteaux sauf électriques qui sont avec
power=pole)
https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_poles_proposal
(pas encore traduite)

C'est dores et déjà utile de compléter les power=pole du réseau de
distribution avec operator=Enedis (dans les communes appropriées
https://dataviz.agenceore.fr/distributeurs-energie-france/) ou d'ajouter
les poteaux Orange de vos environs avec man_made=utility_pole +
utility=telecom + operator=Orange

A suivre pour la suite des événements, bonne soirée

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

Re: [Talk-it] Google trekker

[Volker Schmidt]

Penso che Mapillary ha un vantaggio su percorsi ciclabili e pedonali.
E' anche adesso disponibile senza limiti con licenza aperta addirittura per
uso commerciale.
Sull'aspetto tecnico il loro visualizzatore ê migliore di quello di
Streetview.
Se fate le foto con una camera 360 con GPS incorporato (come Garmin VIRB
360), il risultato è bello.
Guardate le foto 360gradi dell'utente  giubar

.

Volker

On Thu, 3 Sep 2020, 12:28 Alessio Piccioli, 
wrote:

> Ciao a tutti,
>
>   non ho più seguito in dettaglio il discorso di Google ma il CAI
> Nazionale sta con OSM!!! A breve rinnoveremo la convenzione e in questi
> anni sono stati inseriti un sacco di percorsi in tutta Italia siamo a
> 70.000 Km se non erro.
>
> Detto questo l'idea dello StreetView sui sentieri potrebbe essere un
> qualcosa che attrae nei prossimi anni ci sarebbe Mapillary ma anche li
> andiamo su terreno scivoloso in termini di usabilità (licenze e diritti)
> del dato.
>
> E se ci inventassimo qualcosa che parte proprio dal popolo di OSM? (magari
> mi sono perso un pochino e qualcosa già esiste?)
>
> Un saluto a tutte e tutti!!
>
> A.
>
> Il giorno mer 2 set 2020 alle ore 14:45 Manuel  ha
> scritto:
>
>> 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 
>> listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it
>>
>> ___
>> Talk-it mailing 
>> listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
>
> --
> *Alessio Piccioli / *Amministratore unico
> alessiopicci...@webmapp.it
> www.webmapp.it
> +39 328 53 60 803
>
>
> P.Iva e CF 02266770508
> CCIAA di Pisa n. 02266770508 del 01/08/2017
> Capitale Sociale 10.000,00 €
> ___
> 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-hr] Fwd: Import zgrada u Zagrebu

[Janko Mihelić]

čet, 3. ruj 2020. u 16:47 Matija Nalis 
napisao je:

> hm, ne vidim taj source:geometry:dataset bas po taginfu? mozda spojiti u
> jedan:
>
> source:geometry=ZIPP Aerofotogrametrijsko i LiDAR snimanje
> source:geometry:ref=234235 (ovo umjesto zzip_import_id)
> source:geometry:date=2012-03-26
>
> A da se opet zna *cije* je to Aerofotogrametrijsko i LiDAR snimanje...
>

Ja sam za. Imaš pravo, dvostruki datum nije potreban. Budem napravio nove
religijske .osm datoteke sa tagovima. Find Replace.


> S tim da mi ovaj drugi svasta nesto radi, ali javlja gresku
> "confict in 'visible' attribute for object of type node with id 199"
>

Možda ipak treba prvo ovaj drugi link, a onda prvi. U drugom kaže
"new_layer=false" a u prvom "true" pa valjda to radi problem kad proba
spojiti podatke.


> i da li bi trebalo biti u tom drugom URL-u "changeset_source=Bing" ?
> mozda "changeset_source=geoportal.zagreb.hr" ?
>

To stvara Tasking Manager, ima dio gdje se može podesiti imagery, ja nisam
stavio ništa pa je stavio defaultni source=Bing. Ali mi je glupo da u
imagery stavim geoportal.zagreb.hr, pa da se otvori prazno. Možda da
stavimo Zagreb 2018 imagery, ionako ćemo još malo podešavati po njemu.
A mogu staviti i geoportal.zagreb.hr, nije neki problem svaki put otvoriti
imagery..


> Ja sam gledao ovaj:
> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Conflation
> taj isto koristi utilsplugin2 ali je navodno bolji za conflation zbog
> neceg :)
>

Budem probao, sa onim drugim nije baš bilo bezbolno, bilo je dosta ručnog
rada sa spajanjem točaka.



> Ja bih dakle da probamo:
> a) napraviti rucno malo modificiranu fake verziju ovog originalnog ZIPPv1
> dataseta i spremiti kao ZIPPv2.osm
> b) probati sa utilsplugin2 (ili JOSM conflate) pluginom u JOSMu rucno
> conflateati par zgrada po ZIPPv1 (da dobiju import tagove i geometriju)
> c) sa https://wiki.openstreetmap.org/wiki/OSM_Conflator probati
> poluautomatski upgrade sa ZIPPv1 na ZIPPv2 geometrije da vidi da li ce ih
> pokupiti ispravno
>(Samo za te zgrade koje smo rucno conflateali u koraku b) naravno!)
>
> pa tek kada znamo da ce nam to raditi OK, onda da objavimo Task manager...
>

Ok, budem napravio mini .osm fajlu sa nekoliko crkvica pa se možemo igrati.

Za ljude je vjerojatno dovoljno dobro nesto tipa "source:geometry=RUCNO
> radjeno prema a,b,c.  Ne dirati osim ako nova geometrija sigurno nije bolja
> od toga"
> Pa onda ce razmisliti (nadajmo se) prije nego krenes mijenjati geometriju
> toga.
>

Onda je upitno ono što Hrvoje kaže da ionako trebamo namještati po Zagreb
DOF-u 2018. Jer će onda svi biti bar malo drugačiji. Trebalo bi malo
proanalizirati koji postotak bi se namještao:
https://tms.osm-hr.org/

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

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

[Rpnpif via Talk-fr]

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

Quel intérêt de rappeler un doublon désuet ?

Sauf à rappeler que c'est doublon désuet.


maxspeed:type désuet ? La page de wiki de source:maxspeed a été créée en 
2009, celle de maxspeed:type en 2011.


C'est vrai que source:maxspeed est le plus utilisé avec 1,6 millions de 
valeurs alors que maxspeed:type en a 378000 ce qui n'est pas ridicule.


Je connais la discussion sur ce sujet mais pour être exhaustif, il 
fallait citer les deux. D'ailleurs c'est ce que fait la page en anglais 
du wiki sans prendre parti.


Personnellement, j'ai un léger faible pour maxspeed:type car ce n'est 
pas véritablement une source mais plutôt une référence remplaçable par 
une valeur. Les applications qui utilisent la carte, n'utilisent que 
rarement les attributs source:* alors que la valeur FR:urban peut être 
remplacée par une vitesse.

Cela n'a rien a voir avec source=cadastre ou autre.

Mais je ne suis pas intégriste de cet attribut mais je pense qu'il faut 
laisser le choix vu le nombre d'utilisation.


--
Rpnpif

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

Re: [OSM-talk-be] regional cycle routes in Brussels

[Jo]

Yes, I'll look at those as well.

Jo

On Thu, Sep 3, 2020 at 1:00 PM Yves bxl-forever 
wrote:

> Hello,
>
> Thanks for this.
>
> @Polyglot, I saw you updated numbered cycle routes (1 to 12).
> The Brussels cycle route network also has 7 routes with letters.  I
> suppose we should apply the same change.
> A small circle: https://www.openstreetmap.org/relation/237027
> B middle circle: https://www.openstreetmap.org/relation/116569
> C large circle: https://www.openstreetmap.org/relation/7418111
> CC: Canal/Kanaal: https://www.openstreetmap.org/relation/1119347
> SZ Senne/Zenne valley: https://www.openstreetmap.org/relation/116611
> MM Maalbeek valley: https://www.openstreetmap.org/relation/114235
> PP (King’s Palace): https://www.openstreetmap.org/relation/2133184
>
> Cheers.
> Yves
>
>
> On Thu, 3 Sep 2020 10:40:29 +0200
> Jo  wrote:
>
> > I had a look at them after downloading them using Overpass API and
> started
> > making them continuous where they were 'broken'. So I went ahead and also
> > converted them all to rcn.
> >
> > Jo
> >
> > On Thu, Sep 3, 2020 at 9:41 AM Jo  wrote:
> >
> > > Hi Joost,
> > >
> > > In Flanders it depended more on topology than anything else. We used:
> > >
> > > lcn: for loops
> > > rcn: for the numbered node networks, this logic was taken to rwn and
> rhn
> > > later on
> > > ncn: for long routes going from A to B (LFx) and then later for the
> Fxxx
> > > cycle highways
> > > icn: for European routes going from A to B
> > >
> > > In Brussels rcn doesn't seem to be used and those routes are
> topologically
> > > more similar to the numbered routes system used in Flanders and
> Wallonia.
> > >
> > > I agree with you that it makes more sense to tag them as rcn.
> > >
> > > Jo
> > >
> > > On Thu, Sep 3, 2020 at 9:14 AM joost schouppe <
> joost.schou...@gmail.com>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> I was always a little confused that the regional cycle network is
> mapped
> > >> as lcn in Brussels. Since this network is organized by
> Brussels-the-region,
> > >> not Brussels-the-city, it seems logical that it should have the rcn
> tag. In
> > >> fact, more so than the Flemish cycle node network, which is composed
> of
> > >> several networks and almost by coincidence covers the region.
> > >>
> > >> This is also what we say in the wiki:
> > >>
> > >>
> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycle_Routes#Itin.C3.A9raires_Cyclables_R.C3.A9gionaux_-_Gewestelijke_Fietsroute
> > >>
> > >> But the example given there (
> https://www.openstreetmap.org/relation/9623
> > >> I believe), is now mapped as an lcn.
> > >>
> > >> Looking at the edit history, it looks like there was a minor edit war
> > >> about this, where user RoRay repeatedly changed it from rcn to lcn
> > >> https://www.openstreetmap.org/changeset/8141976
> > >> https://www.openstreetmap.org/changeset/12902663
> > >> (RoRay is still mapping, still using the not-very helpful default
> > >> changeset description "update")
> > >>
> > >> User BenoitL tried to change it back to rcn (with much better
> changeset
> > >> comments :) - https://www.openstreetmap.org/changeset/12849599), but
> I
> > >> guess he gave up. Polyglot later seems to have mapped most of the
> other
> > >> routes; my guess is he just went with lcn because that's how the
> others
> > >> were mapped.
> > >>
> > >> Apart from the network not showing up when it should on some maps, it
> > >> doesn't really matter much. However, bxl-forever is now mapping
> -actual-
> > >> lcn routes in the Brussels region, operated by Anderlecht
> municipality.
> > >> Example: https://www.openstreetmap.org/relation/11544325
> > >> Putting both types of routes in the same level is just wrong IMHO.
> > >>
> > >> Can anyone provide some more context? Based on my own research, I'd
> > >> suggest we simply retag all the regional operated routes from lcn to
> rcn.
> > >>
> > >> Best,
> > >> Joost Schouppe
> > >> ___
> > >> Talk-be mailing list
> > >> Talk-be@openstreetmap.org
> > >> https://lists.openstreetmap.org/listinfo/talk-be
> > >>
> > >
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-hr] Fwd: Import zgrada u Zagrebu

[Matija Nalis]

On Fri, Aug 28, 2020 at 01:24:24PM +0200, Hrvoje Bogner wrote:
> On 28. 08. 2020. 02:10, Matija Nalis wrote:
> > Dakle to svakako moramo *negdje* upisati cini mi se?
> > 
> > Da li onda changeset comment, ili u svaki way poseban tag?
> > Postoji li neki standardni nacin za taj attribution davati?
> > 
> > Mislim da je za takve importe required attribution vrlo bitan dio price...
> 
> Atribucija rješena na globalnoj razini:
> 
> https://wiki.openstreetmap.org/wiki/Contributors#Croatia

da, ali opet negdje moramo referencirati (changset tags, source:geometry* 
object tag) 
KOJI od contributorsa je dao podatke za taj specificni objekt/changeset, zar ne?

> DGU DOF je autoritativan za RH, osim za Zagreb, za Zagreb je autoritativan
> ZG DOF 2018.
> 
> Više mjerujem 20cm DOF-u nego 50cm DOF-u, a i njega Zagreb koristi kao
> osnovu na kojoj radi modifikacije vektorskih slojeva.
> 
> Također lidar NIJE 100% točan, za neke objekte je bolje editirati te vektore
> da pašu na ZG DOF 2018.

A prilikom ovog LiDAR 2012 importa dakle opet trebamo gledati Zagreb
2018 Aerial kao autorativan? 

-- 
Opinions above are GNU-copylefted.

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

Re: [Talk-hr] Fwd: Import zgrada u Zagrebu

[Matija Nalis]

On Fri, Aug 28, 2020 at 01:03:21PM +0200, Janko Mihelić wrote:
> pet, 28. kol 2020. u 02:10 Matija Nalis 
> > Ma mislio sam tu da li trebamo mozda staviti
> > "source:geometry=ZIPP Aerofotogrametrijsko i LiDAR snimanje 2012."
> > ili mozda bolje:
> > "source:geometry=geoportal.zagreb.hr Aerofotogrametrijsko i LiDAR
> > snimanje 2012."
> 
> Slažem se da trebamo dodati ZIPP negdje. Malo sam pogledao wiki stranicu za
> source:
> https://wiki.openstreetmap.org/wiki/Key:source
> 
> I mislim da bi trebali sve prebaciti na source tag.
> 
> Recimo,
> source:geometry=Zagrebačka infrastruktura prostornih podataka
> source:geometry:dataset=Aerofotogrametrijsko i LiDAR snimanje 2012.
> source:geometry:ref=234235 (ovo umjesto zzip_import_id)
> source:geometry:date=2012-03-26

hm, ne vidim taj source:geometry:dataset bas po taginfu? mozda spojiti u jedan:

source:geometry=ZIPP Aerofotogrametrijsko i LiDAR snimanje
source:geometry:ref=234235 (ovo umjesto zzip_import_id)
source:geometry:date=2012-03-26

A da se opet zna *cije* je to Aerofotogrametrijsko i LiDAR snimanje...

> 4)   Ili ce mi tasking manager nesto poslati u JOSM preko remote controla ili 
> nekako?
> Da, mogu dati dva linka da se vidi što će doći u JOSM:
> http://localhost:8111/import?new_layer=true=http://adnet.hr/osm/8919_10544.osm
> http://localhost:8111/load_and_zoom?left=15.9741210908886=45.82879924547089=15.996093747134697=45.8441077891506_comment=Manual%20import%20of%20buildings%20in%20Zagreb%20%23osmhr-project-9%20%23ImportZagrebBuildings_source=Bing_layer=false

Cool, nisam znao da to zna slati!

S tim da mi ovaj drugi svasta nesto radi, ali javlja gresku
"confict in 'visible' attribute for object of type node with id 199"

i da li bi trebalo biti u tom drugom URL-u "changeset_source=Bing" ?
mozda "changeset_source=geoportal.zagreb.hr" ?

> Tamo sam napisao da se instalira utilsplugin2 i onda ćeš dobiti

Ja sam gledao ovaj:
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Conflation
taj isto koristi utilsplugin2 ali je navodno bolji za conflation zbog neceg :)

(Ne mijesati "JOSM Conflation plugin" sa 
https://wiki.openstreetmap.org/wiki/OSM_Conflator
koji je nesto sasvim drugo)

> Uglavnom, nije trivijalno, a vjerojatno će još i u svakom primjeru
> biti posebnosti. Recimo, što ako neka cestica prolazi kroz građevinu..
> Zato mislim da je bolje da to rade samo malo iskusniji maperi.

Da, ok, meni ima smisla.

> > 6) sto kada dodje novi dataset? novi ce imati novi source:geometry, npr.
> > source:geometry=geoportal.zagreb.hr Aerofotogrametrijsko i LiDAR snimanje
> > 2025.
> 
> 
> Slažem se, treba napraviti nešto tipa to što si opisao. Ja sam našao
> Hooetnanny:
> https://github.com/ngageoint/hootenanny
> Ali ovo tvoje mi zapravo bolje izgleda. Misliš da bi to trebali prvo
> isprobati prije importa? Možda nam još nešto padne na pamet. Mogli bi
> recimo samo religijske građevine importati, i onda na njima isprobati OSM
> Conflator.

Pa mislim da bi bilo dobro isprobati, a ne da sad napravio na jedan
nacin, a onda jednom kada dodje nova verzija dataseta da skuzimo da
smo neku trivijalu zeznuli pa ne mozemo poluautomatiku koristiti...

Ja bih dakle da probamo:
a) napraviti rucno malo modificiranu fake verziju ovog originalnog ZIPPv1 
dataseta i spremiti kao ZIPPv2.osm
b) probati sa utilsplugin2 (ili JOSM conflate) pluginom u JOSMu rucno 
conflateati par zgrada po ZIPPv1 (da dobiju import tagove i geometriju)
c) sa https://wiki.openstreetmap.org/wiki/OSM_Conflator probati poluautomatski 
upgrade sa ZIPPv1 na ZIPPv2 geometrije da vidi da li ce ih pokupiti ispravno
   (Samo za te zgrade koje smo rucno conflateali u koraku b) naravno!)

pa tek kada znamo da ce nam to raditi OK, onda da objavimo Task manager...

> > 7) sto kada dodje novi dataset? Gledam po
> > https://wiki.openstreetmap.org/wiki/OSM_Conflator naime pa oni koriste
> > "ref:dataset" tag, koji je isti bez obzira o reviziji podataka koje
> > importaju?
> >
> > mozda bi i mi trebali "ref:dataset" staviti?
> > i/ili maknuti godinu iz "source:geometry", a ostaviti je u
> > "source:geometry:date" ?
> > koja je uopce razlika izmedju "ref:dataset" i "source:geometry" ?
> >
> 
> Gore sam ono što je u source:geometry preimenovao u source:geometry:dataset. 

A da li ce https://wiki.openstreetmap.org/wiki/OSM_Conflator znati raditi ako 
nema ref:dataset (ili ako je drugaciji od onoga sto je bio prije [zbog godine u 
nazivu dataseta]) ?

To sam mislio da probamo pa vidimo...

> E sad,micati godinu?  Ne znam, ja bi ostavio isto ako se nije
> promijenila geometrija.  Inače bi morali na svim elementima svakih
> x godina promijeniti source:geometry:date tagove, iako se ništa ne
> mijenja.  To mi se nekako čini suvišno.

Pa ne bih rekao da je suvisno, jer onda znamo da zgrada i tog novog
datuma i dalje zadovoljava tu geometriju i tag (nije srusena, 
nadogradjivana, prenamjenjena iz crkve u birtiju itd).  Kao sto npr. 
https://wiki.openstreetmap.org/wiki/Key:check_date mijenjas i kada je
to 

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

[osm . sanspourriel]

Quel intérêt de rappeler un doublon désuet ?

Sauf à rappeler que c'est doublon désuet.

Jean-Yvon

Le 03/09/2020 à 16:30, Rpnpif via Talk-fr - talk-fr@openstreetmap.org a
écrit :

Bonjour,

Le 03/09/2020 à 03:38, Marc Mongenet a écrit :

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:


Et comme ce serait trop simple, je rappelle qu'il existe aussi
maxspeed:type comme synonyme de source:maxspeed. Le premier est oublié
sur le wiki en français.




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

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

[Rpnpif via Talk-fr]

Le 01/09/2020 à 19:13, Georges Dutreix via Talk-fr a écrit :

Bonjour,

J'ai souvent découpé des giratoires pour des lignes de bus : honte sur 
moi !

Promis, je ne le ferai plus ;-)

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


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



+1 ! Tout à fait d'accord.

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

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

[Rpnpif via Talk-fr]

Bonjour,

Le 03/09/2020 à 03:38, Marc Mongenet a écrit :

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:


Et comme ce serait trop simple, je rappelle qu'il existe aussi 
maxspeed:type comme synonyme de source:maxspeed. Le premier est oublié 
sur le wiki en français.


--
Rpnpif

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

Re: [Talk-GB] Pedestrian priority and highway=cycleway

[Andy Townsend]

On 03/09/2020 10:58, Gareth L wrote:

I think the permissive tag is due to it being yet another perceived public 
space which is actually private, so there’s no public right of way.

Would access=permissive or access:bicycle=permissive be sensible? Or is that 
also mangling tagging conventions. I genuinely don’t know!

Gareth


Yes - bicycle=permissive seems correct based on the description so far 
(not that I've been there) if there's no public right of way.  We're 
talking England here, not somewhere enlightened like Scandinavia or 
Scotland.


Best Regards,

Andy


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

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

[Philippe Verdy]

Seulement les arrêts c'est ingérable, on obtient un nuage de points, et
l'ordre en plus n'est pas garanti (pas moyen de le manipuler dans iD par
exemple, un point défusionné et recréé à côté sera systémqtiquement mis en
fin de liste. Donc à moins de numéroter les arrêts dans l'ordre... On se
retrouve dans la même situation qu'un nuage de points pour les services à
la demande (sans aucun itinéraire ni aucun temps de parcours calculable ou
prévisible, même avec une marge d'erreur).

Les itinéraires sont utiles (même s'il passent par des ronds-points non
découpés, ce qui ne change que quelques secondes au cas où un
itinéraire voudrait faire la boule entière et un peu plus, ce qui est
rarement le cas sauf pour faire demi-tour sur une branche: là aussi le
nuage de point ne détecte pas ce cas, et va minorer le temps de trajet ou
calculer n'importe quoi) ou du cas de l'arrêt sur le rond-point lui-même
nécessitant d'en faire le tour complet ou un peu plus pour le desservir).

De toute façon tous les itinéraires ont une petite marge de variation de
trajet (travaux avec déviations) ou de temps de parcours (pour les bus cela
peut monter à quelques minutes en service normal). On a souvent des arrêts
déplacés (le plus souvent signalés car prévus à l'avance, sauf cas spécial
comme un accident, une manif ou une affluence inhabituelle, les causes
festives étant cependant souvent organisées à l'avance par l'autorité
publique et signalées): un rond-point gardé entier ne change rien de façon
significative par rapport aux aléas de conditions de circulation et
d'affluence variable dans les bus. Et ça vaut aussi pour les trajets en
véhicule particulier ou en taxi ou auto-partage (là aussi une variabilité
de l'ordre du quart d'heure pour nombre de trajets, sauf desserte
très locale pour quelques kilomètres au plus où ça descend un peu, et les
trajets très longs passant par les grandes infrastructures routières, mais
il peut arriver sur ces trajets de plus de 200 km des retards atteignant
facilement l'heure sur des points de congestion urbains: là encore les
ronds-points sont insignifiants et en cas de congestion il y a des
itinéraires "bis" qui éventuellement peuvent faire gagner un peu de temps
ou en perdre mais là souvent les conducteurs n'ont pas trop le choix).

Pour les trajets à pied c'est très indicatif, chacun marche comme il veut à
la vitesse qu'il veut, et fait autant d'arrêt qu'il veut selon ses envies
ou sa condition. Même chose pour les trajets cyclistes.

En pratique, quand on prend un bus ou un car, on a besoin de ces
itinéraires ordonnés pour savoir quand descendre et demander les arrêts
suivants (bouton de signalement au chauffeur) et se repérer sur le parcours
(sauf cas des lignes directes où on n'a pas besoin de surveiller) et savoir
que l'arrêt suivant du parcours habituel est desservi ou pas (de nombreuses
lignes ont des variante de parcours: il faut savoir quel bus prendre et
repérer s'il vaut mieux attendre le suivant, en s'aidant des fiches
horaires).

Mettre les itinéraires permet de reconstituer l'ordre des arrêts, faire les
diagrammes, construire des fiches horaires et les rendre lisibles et à
chacun de pouvoir avoir une bonne idée de la variabilité du temps de
parcours. Et pour certaines lignes il est même possible de demander des
arrêts à la demande le long du parcours sur des arrêts facultatifs mais
disposant d'emplacements adéquats (ce cas est courant en milieu très rural
où les arrêts signalés sont très distants entre eux) ; ça dépend des règles
de chaque réseau et ce que le chauffeur a le droit de faire selon sa
compagnie, mais aussi de la politesse et de la conduite pour cette demande,
ainsi que de l'affluence dans les bus: si le bus est déjà en trop en retard
et a du monde, les autres passagers ont aussi un avis important : c'est un
règlement social implicite (et on ne peut pas obliger un chauffeur à sortir
non plus des règles du code de la route et accélérer ou faire une
manœuvre dangereuse selon son jugement où il a l'autorité et une
responsabilité pénale et civile vis à vis de ses passagers, sa compagnie,
et les autres usagers de la voie publique).

Si on commence à ne plus mettre les trajets et juste les arrêts, alors
autant ne plus rien mettre dans OSM et laisser ça aux cartes et
applications des sociétés de transport et leurs fiches horaires (pas
toujours très lisibles).

Le mer. 2 sept. 2020 à 20:26, Gad.Jo  a écrit :

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

Re: [OSM-talk-fr] Zaclys

[Jacques Lavignotte]

Le 03/09/2020 à 15:17, Vincent Bergeot a écrit :

Le 03/09/2020 à 15:09, pepilepi...@ovh.fr a écrit :

Et juste pour ma culture : c'est qui, Zacklys ?


un chaton, fournisseur de services web https://www.zaclys.com/ (un bel 
exemple autour de nextcloud avec nombreux serveurs et du mail)


+111


Vincent Bergeot


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] test n° 3 depuis Thunderbird

[Vincent Bergeot]

Le 03/09/2020 à 15:09, pepilepi...@ovh.fr a écrit :

Et juste pour ma culture : c'est qui, Zacklys ?


un chaton, fournisseur de services web https://www.zaclys.com/ (un bel 
exemple autour de nextcloud avec nombreux serveurs et du mail)


à plus

--
Vincent Bergeot

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

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

[roptat]

Idem, pas de n°2 ici. Pourtant j'ai mon propre serveur et il est plutôt laxiste 
sur ce qu'il laisse entrer (je bloque seulement une poigné d'expéditeurs, pas 
de filtrage pour les spam, …).

Le 3 septembre 2020 09:09:59 GMT-04:00, "pepilepi...@ovh.fr" 
 a écrit :
>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.
>
>
>Bonjour (re),
>
>Comme d'autres je n'ai pas reçu de N° 2.
>
>Et juste pour ma culture : c'est qui, Zacklys ?
>
>Bonne journée,
>
>JP
>
>
>>
>> Merci beaucoup.
>> Georges
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>-- 
>
>
>Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé
>la
>bonne question.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[pepilepi...@ovh.fr]

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.


Bonjour (re),

Comme d'autres je n'ai pas reçu de N° 2.

Et juste pour ma culture : c'est qui, Zacklys ?

Bonne journée,

JP


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


-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question.

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

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

[Johann Haag]

Mir wäre Neu, dass es im Internet Bergrouten gibt, Bergrouten gibt es am
Berg.
In OpenStreetMap kann man sich unter osm.org öffentliche GPS-Tracks
einblenden. Ich finde derlei Schwarmintelligenz zum erkennen von
Hauptrouten jedenfalls sehr nützlich, praktisch und auch verlässlich.
Auch offizielle Karten können irren, https://youtu.be/oYdmqf_P8DM?t=165

Grüße Johann

Am Do., 27. Aug. 2020 um 12:39 Uhr schrieb PPete :

> Gestern gab es in ORF-Bundesland heute OÖ einen Bericht (mit jenem Titel)
> über einige kürzlich stattgefundene Bergrettungseinsätze, die teilweise mit
> falsch eingetragenen Pfaden in der OSM oder der Verwendung von ungeeigneten
> Karten zum Bergwandern zu tun haben. Zu einem der Fälle gabs kürzlich auch
> einen Bericht in den OÖN. Siehe:
>
> https://ooe.orf.at/stories/3064030/
>
> https://www.nachrichten.at/oberoesterreich/abkuerzung-per-routenapp-aufwendige-rettungsaktion-im-toten-gebirge;art4,3286408
>
> Beim Fall am Mittagkogel geht's vermutlich um die Strecke vom Rinnerkogel
> (2012 m) zum Mittagkogel (1823 m) und in weiterer Folge über die
> Grünbergalm runter zum Offensee:
> https://www.openstreetmap.org/#map=15/47.7238/13.8372
>
> Ich muss sagen, ich kenne den Weg und Gegebenheiten vorort nicht, aber es
> hört sich für mich an dass sich der Mapper damals Gedanken darüber gemacht
> hat und Schwierigkeit und Sichtbarkeit so bewertet, dass er als schlecht
> sichtbarer, sehr schwieriger alpiner Steig eingetragen ist.
> Der Pfad hat "sac_scale=demanding_alpine_hiking" und
> "trail_visibility=horrible"
>
> Nun das große Problem aus meiner Sicht: Es gibt nur sehr wenige Karte die
> diese OSM-Skalen auch darstellen und man schon bei der Planung oder später
> unterwegs sieht, was für ein Pfad einem in etwa erwartet. Wenn ihr euch den
> obigen Openstreetmap-Link anschaut sehen darauf alle Pfade gleich aus, ein
> rot gepunktete Linie. Also ein kaum sichtbarer hochalpiner Steig genauso
> wie ein einfaches, bestens markiertes Wanderwegerl durch flachen Wald.
>
> Vorbildlich wird dies soweit mir bekannt nur z.b. auf OpenAndroMaps-Karten
> dargestellt (die ich selber schon lange als Standarkarte am Handy verwende)
> wo Pfade nach Farben (=Schwierigkeit) und Strichlängen (=Sichtbarkeit) zu
> unterschieden sind. Der angesprochene Weg ist darin schwarz (sehr schwer)
> und punktiert (sehr schlechte sichtbarkeit) dargestellt.
>
> Letztendlich bleibt die Eigenverantwortlichkeit das man sich vor so einer
> alpinen Tour über geeignetes Kartenmaterial informiert. Und zweitens muss
> man sich ev. als Kartenanbieter auch fragen ob ich wirklich jedes
> hochalpine Steiglein aus den OSM-Daten in meine Karte einzeichne, wenn
> diese darin nicht von gewöhnlichen, gefahrlosen Wanderwegerl unterscheidbar
> sind.
>
> Dann wird vom Bergrettungsmann im ORF-Bericht noch ein Steig nördlich des
> Krippensteins erwähnt bzw. am PC gezeigt, der angeblich gar nicht vorhanden
> ist und auch schon zu Einsätzen geführt hat. Was damit machen? Ihn löschen
> und der Bergrettung über die Löschung Bescheid geben? Oder vorher mit ihr
> Kontakt aufnehmen und fragen welche Abschnitte genau zu löschen sind? Er
> hat gesagt er hätte zum "Kartenanbieter" Kontakt aufgenommen, aber
> scheinbar ohne "Erfolg", der Pfad dürfte immer noch vorhanden sein.
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>


-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

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

[Mike Thompson]

On Wed, Sep 2, 2020 at 7:34 PM brad  wrote:

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

Re: [OSM-talk-fr] bâtiments composites / fusion de polygones ?

[osm . sanspourriel]

Correction de ma réponse.


Le bon type pour l'exemple au-dessus serait "toit" ?


oui (roof=no en termes d'attributs).


En fait c'est building=roof.

Sinon la réponse reste la même.

Jean-Yvon


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

Re: [OSM-talk-fr] bâtiments composites / fusion de polygones ?

[Julien Lepiller]

Le Thu, 3 Sep 2020 14:20:36 +0200,
osm.sanspourr...@spamgourmet.com a écrit :

> Le 03/09/2020 à 13:56, draenog - drae...@harinezumi.fr a écrit :
> 
> > Je contribue quasi exclusivement depuis mon téléphone,
> > StreetComplete / Vespucci (un peu, je découvre), et cela me
> > semblait curieux de demander (StreetComplete) des numéros de rue
> > plusieurs fois pour le même lieu (mais est-ce gênant pour OSM ?)  
> 
> SC a des requêtes pourrissant pas mal la base comme demander plusieurs
> adresses à un bâtiment.
> 
> Au moins en France on veut ne voir qu'une adresse et plutôt au droit
> de l'accès principal.
> 
> Et qu'elle soit dans une associatedStreet si c'est une adresse de rue.
> 
> Avec plusieurs adresses il y a du travail pour afficher une carte
> propre. J'ai déjà vu des coins ou les adresses 12 pullulaient mais peu
> d'autres d'adresses dans le coin.
> 
> Et tu imagines que si tu demandes d'aller au "13 rue de la Mairie" on
> demande si tu veux aller :
> - au toit "13 rue de la Mairie"
> - au bâtiment de plain-pied "13 rue de la Mairie"
> - au bâtiment de deux étages "13 rue de la Mairie"
> 
> etc...

C'est pour ça qu'il faudrait regrouper les bouts sous un seul bâtiment
: un `building=*` qui fait le tour de tous les bouts, et passer chaque
bout en building:part, au lieu de building. D'un côté on a un bâtiment
logique, et chaque bout peut coder un nombre d'étage différent, un type
différent, etc.

> 
> De plus avec les possibilités d'intégrer les adresses depuis le
> cadastre, il serait raisonnable de déactiver cette quête sur SC. Et
> d'inciter à utiliser dev.cadastre.openstreetmap.fr à la place.
> 
> C'est un peu comme demander le revêtement de la route sur une
> départementale en France : dans 99 % des cas c'est surface=asphalt. Je
> pense qu'on a mieux à faire que demander le revêtement de la route.
> 
> Je ne dis pas que surface est sans intérêt mais seulement quand la
> surface est étonnante ou que vu le type de voirie ça n'a rien
> d'évident.
> 
>  > Je contribue quasi exclusivement depuis mon téléphone,  
> 
> C'est un peu le problème : en contribuant via SC tu n'a pas forcément
> les bons outils.
> 
> Je ne dis pas que SC ne peut pas être utile mais qu'il est utilisé de
> manière sous optimale. A cause des quêtes pas des utilisateurs^^.
> 
> > Le bon type pour l'exemple au-dessus serait "toit" ?  
> 
> oui (roof=no en termes d'attributs).

non, ça ça veut dire qu'il n'y a *pas* de toit :)

C'est plutôt `building=roof`, non ?

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


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

Re: [OSM-talk-fr] bâtiments composites / fusion de polygones ?

[osm . sanspourriel]

Le 03/09/2020 à 13:56, draenog - drae...@harinezumi.fr a écrit :


Je contribue quasi exclusivement depuis mon téléphone, StreetComplete
/ Vespucci (un peu, je découvre), et cela me semblait curieux de
demander (StreetComplete) des numéros de rue plusieurs fois pour le
même lieu (mais est-ce gênant pour OSM ?)


SC a des requêtes pourrissant pas mal la base comme demander plusieurs
adresses à un bâtiment.

Au moins en France on veut ne voir qu'une adresse et plutôt au droit de
l'accès principal.

Et qu'elle soit dans une associatedStreet si c'est une adresse de rue.

Avec plusieurs adresses il y a du travail pour afficher une carte
propre. J'ai déjà vu des coins ou les adresses 12 pullulaient mais peu
d'autres d'adresses dans le coin.

Et tu imagines que si tu demandes d'aller au "13 rue de la Mairie" on
demande si tu veux aller :
- au toit "13 rue de la Mairie"
- au bâtiment de plain-pied "13 rue de la Mairie"
- au bâtiment de deux étages "13 rue de la Mairie"

etc...

De plus avec les possibilités d'intégrer les adresses depuis le
cadastre, il serait raisonnable de déactiver cette quête sur SC. Et
d'inciter à utiliser dev.cadastre.openstreetmap.fr à la place.

C'est un peu comme demander le revêtement de la route sur une
départementale en France : dans 99 % des cas c'est surface=asphalt. Je
pense qu'on a mieux à faire que demander le revêtement de la route.

Je ne dis pas que surface est sans intérêt mais seulement quand la
surface est étonnante ou que vu le type de voirie ça n'a rien d'évident.

> Je contribue quasi exclusivement depuis mon téléphone,

C'est un peu le problème : en contribuant via SC tu n'a pas forcément
les bons outils.

Je ne dis pas que SC ne peut pas être utile mais qu'il est utilisé de
manière sous optimale. A cause des quêtes pas des utilisateurs^^.


Le bon type pour l'exemple au-dessus serait "toit" ?


oui (roof=no en termes d'attributs).

Jean-Yvon




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

Re: [Talk-it] Google trekker

[Martin Koppenhoefer]

c’è da anni e con modesto progresso anche un progetto open, si chiama open 
trail view, penso il problema è l’hosting di petabytes di immagini ;-)

non so si qualcosa crowd funded potrebbe funzionare. Forse si potrebbe 
interessare wikimedia, che hanno i soldi...

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

[talk-cz] Kvartální (ne)pivo

[Tom Ka]

Ahoj,

včera jsme opět v (post)covidové době vynechali kvartální pivo, tak
kdo si aspoň doma otevřel lahváč a zamáčkl slzu má bod :-)

Bye tom.k

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

Re: [OSM-talk-fr] bâtiments composites / fusion de polygones ?

[draenog]

Merci de vos réponses,

Effectivement sur la photo correspondant à l'exemple que j'avais mis en 
lien, l'avant semble être un porche d'accès à l'entrée et le côté un 
abri (à bois ?). Je n'avais pas non plus pensé aux différences de niveaux.


Je contribue quasi exclusivement depuis mon téléphone, StreetComplete / 
Vespucci (un peu, je découvre), et cela me semblait curieux de demander 
(StreetComplete) des numéros de rue plusieurs fois pour le même lieu 
(mais est-ce gênant pour OSM ?)


Le bon type pour l'exemple au-dessus serait "toit" ?
code de la quête SC "type de bâtiment" : 
https://github.com/westnordost/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/quests/building_type/AddBuildingType.kt#L13
code inventaire/tag SC des bâtiments : 
https://github.com/westnordost/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/quests/building_type/BuildingTypes.kt#L56




Le 28/08/2020 à 16:28, Philippe Verdy a écrit :
Les zones claires sont effectivement des parties non complètement 
fermées: on ne les identifie pas forcément sur l'imagerie aérienne quand 
il y a un même toit. Mais c'est considéré comme "à l'extérieur". 
Souvent des porches d'entrée couverts, ou un bout de terrasse couverte 
le long de la maison, parfois avec une véranda partiellement fermée par 
un vitrage ou une grille légère, et en tout cas pas isolé. Cela 
approte juste de l'ombrage ou la protection contre la pluie, de quoi 
rester au sec le temp de s'essuyer les pieds, trouver ses clés, poser un 
sac...


Il n'y a pas forcément de diférence de hauteur. Pour le voir il faut une 
photographie au niveau du sol ou à 45 degrés, mais l'orthophoto 
verticale ne fait pas la distinction.


Ce serait bien d'avoir aussi des images à 45 degrés, mais il y en a peu 
(cela demande une couverture aérienne couteuse, par avion/hélico ou par 
drone, et la surface couverte est forcément plus petite: il faut 
multiplier les jeux d'images sources, la couverture territoriale n'est 
pas aussi bonne qu'en orthophoto verticale.


Si c'est en milieu urbain dense on peut voir les façades de la voie 
publique mais pas les arrières, et on ne voit pas non plus à travers 
murs et haies.


Bref en attendant faire confiance au cadastre "a priori". La seule chose 
à faire concerne plutôt les coupures abitraires qui ne sont visiblement 
pas des porches ou galeries extérieures, tronçonnant des restangle en 
triangles de taille inappropriée pour quoi que ce soit et qu'on ne voit 
même pas dans le cadastre lui-même, je me demande d'où viennet ces 
coupures, qui pourraient venir d'un artefact de l'outil d'improt qui a 
procédé par zones de sélection arbitraire), et sinon réorienter (il y a 
parfois des batiments mal orientés, certains n'existent visiblement plus 
et ont été démolis et voire remplacés par d'autres de taille et position 
très différente).



Le mer. 26 août 2020 à 13:59, roptat > a écrit :


De ce que je vois les trois autres parties n'ont pas les mêmes
attributs : ce sont de bouts "sans murs" (correspond à une zone plus
claire sur le cadastre). En général c'est un balcon, une véranda, un
porche, …

Ce que tu peux peut-être faire c'est créer un bâtiment global, et
passer chaque partie en building:part.

Le 26 août 2020 02:12:30 GMT-04:00, draenog mailto:drae...@harinezumi.fr>> a écrit :

Bonjour,

J'ai commencé à contribuer avec StreetComplete, et pour les quêtes "type
de bâtiment" je tombe assez souvent sur des bâtiments composites suite à
l'import cadastre (ex :https://www.openstreetmap.org/way/64141846  
maison en 4 morceaux). Mais la maison me semble un tout cohérent :

https://wtf.roflcopter.fr/pics/Mb6sQLC6/C9cBjJVm.jpg

Ça ne relève pas de StreetComplete, avec quel outil est-il possible de
fusionner les chemins ?
Et surtout, est-ce que c'est la bonne chose à faire ?


draenog

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]

Info pro ostatni - jsme domluveni na pracovni obed ve Ct 10.09.2020 v
11:30 v restauraci Nota Bene u Obilního trhu v Brne. Pokud by se chtel
nekdo pridat, budu jen rad.

Bye tom.k

st 2. 9. 2020 v 20:21 odesílatel Tom Ka  napsal:
>
> 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-au] Contributions to Road Geometry in Perth,

[Ian Steer]

>Date: Thu, 03 Sep 2020 19:23:21 +1000
>From: "Sebastian S." 
>Subject: Re: [talk-au] Contributions to Road Geometry in Perth,
>   Australia
>Hi,
>I have made excessive use of the node tag for islands.
>Particularly for pedestrian crossing.
>
>Splitting the road into two separate ways for only a few metres seems 
>excessive to me. Even when there is a several Meter long raised kerb 
>separating the lanes I would not >split the road.

Could you please elaborate on this method you have been using ?

Ian


On 1 September 2020 10:05:42 pm AEST, Andrew Harvey  
wrote:
>Heads up, looks like their team has started to map in Perth, see on 
>OSMCha
>-> https://osmcha.org/?aoi=80b50a6d-6bb5-48cb-8ac4-4b2ddd9d5d76
>
>Mostly looks okay to me, and mostly minor tweaks, though I raised a few 
>questions and issues on changeset comments but also listed most of them
>here:
>
>https://www.openstreetmap.org/way/840589945/history was added but the 
>existing road name and other applicable attributes were not applied.
>This
>same issue happens in quite a few other places too so appears to be 
>systemic. I've raised some changeset comments but worth including this 
>as part of the standard practice by your editing team.
>
>https://www.openstreetmap.org/way/842851495/history is that a 
>roundabout? I can't tell from the Maxar imagery, yet that is the 
>claimed source, how could you tell from the imagery what this is?
>
>I personally find splitting ways for a traffic island at roundabouts 
>like in https://www.openstreetmap.org/way/840189281/history a tad to 
>excessive (would prefer to just tag the node as traffic island and use 
>one way, gives a much cleaner dataset as the transition between dual 
>and single carriageways is always messy) but I guess it's not wrong and 
>both styles are popular in OSM currently. Does the community have a 
>view on this?
>
>Unclear source of the turn restriction in
>https://www.openstreetmap.org/changeset/90223764#map=18/-32.04553/115.8
>0953
>
>On Sun, 16 Aug 2020 at 21:28, OSM NextBillion. AI 
>wrote:
>
>> Thank you cleary for valuable insights, we would be more cautious
>while
>> mapping in such areas. While Satellite Imagery is our prime resource,
>we’d
>> consider mapillary photos as well wherever available. We do have some 
>> expert assistance in our team for interpreting satellite imagery and
>map
>> something only if we’re double sure of it’s existence. We will refer
>to
>> mappers history before editing existing data to understand if it was 
>> created using local expertise and would change only if there is
>conclusive
>> evidence from satellite and mapillary imageries.
>>
>> We will reach out to local mapping experts through forum and/or
>changeset
>> comments if we require further help.
>>
>> Thank you all once again for the suggestions, we look forward to
>working
>> with you all. :)
>>
>>
>> On Sun, 16 Aug 2020 at 05:35, cleary  wrote:
>>
>>>
>>> Thanks for the interest in mapping in Australia and thanks for
>posting
>>> your plans on this list.
>>>
>>> I would add to the caution expressed by others.  I live in an urban 
>>> location in Australia but I have travelled in other areas within 
>>> Australia.  It has taken me quite some time to learn to interpret
>satellite
>>> imagery and I still have a lot to learn about this country.  After 
>>> personally visiting areas and noting what I see, and sometimes
>taking
>>> photographs, I then return home and compare my notes with what I see
>in the
>>> imagery and I am still surprised.  I think it can be quite
>precarious to
>>> map features using just satellite imagery unless you have expert
>assistance
>>> in interpreting the imagery.  For example, a common error by others
>has
>>> been to map lines of cleared vegetation as roads when they are
>actually
>>> fences. Even where an unmapped road exists, it is probably still
>unmapped
>>> because it is a private road and not accessible by the public - many
>of the
>>> roads on rural properties in Australia are private and, if added to
>the
>>> map, need to marked as such. Farmers get annoyed about intruders on
>their
>>> farms especially as biosecurity is a significant concern in parts of 
>>> Australia.
>>>
>>> So while I appreciate contributions to the map, I suggest that
>"armchair"
>>> mapping needs to be undertaken with a lot of caution.
>>>
>>>
>>>
>>>
>>> On Sat, 15 Aug 2020, at 2:17 AM, OSM NextBillion. AI wrote:
>>> > Hi all,
>>> >
>>> >
>>> >
>>> > We’re a small team based out of Hyderabad, India. We would be
>doing
>>> > minimal edits in Perth and contribute to OSM in the next couple of 
>>> > weeks, in-line with OSM and Australia specific tagging guidelines
>[Link
>>> >
>].
>>> >
>>> >
>>> > Please refer our Wiki
>>> >  and
>Github
>>> >  project pages
>for
>>> > more information.
>>> >
>>> > Looking 

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

[Robert Skedgell]

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

I see this fairly often. Usually the local council who are responsible
for the highway lay the new cycle lane, but cannot move the lamp posts
as UK Power Networks(?) have to deal with them and the associated cabling.

In Greater London we also have bus stops "left" on cycle tracks at new
bus stop bypasses, until Transport for London's contractors can move them.

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

Re: [OSM-talk-be] regional cycle routes in Brussels

[Yves bxl-forever]

Hello,

Thanks for this.

@Polyglot, I saw you updated numbered cycle routes (1 to 12).
The Brussels cycle route network also has 7 routes with letters.  I suppose we 
should apply the same change.
A small circle: https://www.openstreetmap.org/relation/237027
B middle circle: https://www.openstreetmap.org/relation/116569
C large circle: https://www.openstreetmap.org/relation/7418111 
CC: Canal/Kanaal: https://www.openstreetmap.org/relation/1119347
SZ Senne/Zenne valley: https://www.openstreetmap.org/relation/116611
MM Maalbeek valley: https://www.openstreetmap.org/relation/114235
PP (King’s Palace): https://www.openstreetmap.org/relation/2133184

Cheers.
Yves


On Thu, 3 Sep 2020 10:40:29 +0200
Jo  wrote:

> I had a look at them after downloading them using Overpass API and started
> making them continuous where they were 'broken'. So I went ahead and also
> converted them all to rcn.
> 
> Jo
> 
> On Thu, Sep 3, 2020 at 9:41 AM Jo  wrote:
> 
> > Hi Joost,
> >
> > In Flanders it depended more on topology than anything else. We used:
> >
> > lcn: for loops
> > rcn: for the numbered node networks, this logic was taken to rwn and rhn
> > later on
> > ncn: for long routes going from A to B (LFx) and then later for the Fxxx
> > cycle highways
> > icn: for European routes going from A to B
> >
> > In Brussels rcn doesn't seem to be used and those routes are topologically
> > more similar to the numbered routes system used in Flanders and Wallonia.
> >
> > I agree with you that it makes more sense to tag them as rcn.
> >
> > Jo
> >
> > On Thu, Sep 3, 2020 at 9:14 AM joost schouppe 
> > wrote:
> >  
> >> Hi,
> >>
> >> I was always a little confused that the regional cycle network is mapped
> >> as lcn in Brussels. Since this network is organized by Brussels-the-region,
> >> not Brussels-the-city, it seems logical that it should have the rcn tag. In
> >> fact, more so than the Flemish cycle node network, which is composed of
> >> several networks and almost by coincidence covers the region.
> >>
> >> This is also what we say in the wiki:
> >>
> >> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycle_Routes#Itin.C3.A9raires_Cyclables_R.C3.A9gionaux_-_Gewestelijke_Fietsroute
> >>
> >> But the example given there (https://www.openstreetmap.org/relation/9623
> >> I believe), is now mapped as an lcn.
> >>
> >> Looking at the edit history, it looks like there was a minor edit war
> >> about this, where user RoRay repeatedly changed it from rcn to lcn
> >> https://www.openstreetmap.org/changeset/8141976
> >> https://www.openstreetmap.org/changeset/12902663
> >> (RoRay is still mapping, still using the not-very helpful default
> >> changeset description "update")
> >>
> >> User BenoitL tried to change it back to rcn (with much better changeset
> >> comments :) - https://www.openstreetmap.org/changeset/12849599), but I
> >> guess he gave up. Polyglot later seems to have mapped most of the other
> >> routes; my guess is he just went with lcn because that's how the others
> >> were mapped.
> >>
> >> Apart from the network not showing up when it should on some maps, it
> >> doesn't really matter much. However, bxl-forever is now mapping -actual-
> >> lcn routes in the Brussels region, operated by Anderlecht municipality.
> >> Example: https://www.openstreetmap.org/relation/11544325
> >> Putting both types of routes in the same level is just wrong IMHO.
> >>
> >> Can anyone provide some more context? Based on my own research, I'd
> >> suggest we simply retag all the regional operated routes from lcn to rcn.
> >>
> >> Best,
> >> Joost Schouppe
> >> ___
> >> Talk-be mailing list
> >> Talk-be@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-be
> >>  
> >  

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

Re: [Talk-it] Google trekker

[Manuel]

Ci sarebbe OpenStreetCam , ma 
ricordo che anche quello era stato acquistato da un'azienda (la Grab 
) non proprio pulita.
Manuel
Il 03/09/2020 12:26, Alessio Piccioli ha scritto:

Ciao a tutti,

  non ho più seguito in dettaglio il discorso di Google ma il CAI Nazionale sta 
con OSM!!! A breve rinnoveremo la convenzione e in questi anni sono stati 
inseriti un sacco di percorsi in tutta Italia siamo a 70.000 Km se non erro.

Detto questo l'idea dello StreetView sui sentieri potrebbe essere un qualcosa 
che attrae nei prossimi anni ci sarebbe Mapillary ma anche li andiamo su 
terreno scivoloso in termini di usabilità (licenze e diritti) del dato.

E se ci inventassimo qualcosa che parte proprio dal popolo di OSM? (magari mi 
sono perso un pochino e qualcosa già esiste?)

Un saluto a tutte e tutti!!

A.

Il giorno mer 2 set 2020 alle ore 14:45 Manuel mailto:mannivuw...@gmail.com>> ha scritto:

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



--
*Alessio Piccioli / *Amministratore unico
alessiopicci...@webmapp.it 
www.webmapp.it 
+39 328 53 60 803


P.Iva e CF 02266770508
CCIAA di Pisa n. 02266770508 del 01/08/2017
Capitale Sociale 10.000,00 €

___
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-be] regional cycle routes in Brussels

[joost schouppe]

Thank you Jo!

Op do 3 sep. 2020 om 10:41 schreef Jo :

> I had a look at them after downloading them using Overpass API and started
> making them continuous where they were 'broken'. So I went ahead and also
> converted them all to rcn.
>
> Jo
>
> On Thu, Sep 3, 2020 at 9:41 AM Jo  wrote:
>
>> Hi Joost,
>>
>> In Flanders it depended more on topology than anything else. We used:
>>
>> lcn: for loops
>> rcn: for the numbered node networks, this logic was taken to rwn and rhn
>> later on
>> ncn: for long routes going from A to B (LFx) and then later for the Fxxx
>> cycle highways
>> icn: for European routes going from A to B
>>
>> In Brussels rcn doesn't seem to be used and those routes are
>> topologically more similar to the numbered routes system used in Flanders
>> and Wallonia.
>>
>> I agree with you that it makes more sense to tag them as rcn.
>>
>> Jo
>>
>> On Thu, Sep 3, 2020 at 9:14 AM joost schouppe 
>> wrote:
>>
>>> Hi,
>>>
>>> I was always a little confused that the regional cycle network is mapped
>>> as lcn in Brussels. Since this network is organized by Brussels-the-region,
>>> not Brussels-the-city, it seems logical that it should have the rcn tag. In
>>> fact, more so than the Flemish cycle node network, which is composed of
>>> several networks and almost by coincidence covers the region.
>>>
>>> This is also what we say in the wiki:
>>>
>>> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycle_Routes#Itin.C3.A9raires_Cyclables_R.C3.A9gionaux_-_Gewestelijke_Fietsroute
>>>
>>> But the example given there (https://www.openstreetmap.org/relation/9623
>>> I believe), is now mapped as an lcn.
>>>
>>> Looking at the edit history, it looks like there was a minor edit war
>>> about this, where user RoRay repeatedly changed it from rcn to lcn
>>> https://www.openstreetmap.org/changeset/8141976
>>> https://www.openstreetmap.org/changeset/12902663
>>> (RoRay is still mapping, still using the not-very helpful default
>>> changeset description "update")
>>>
>>> User BenoitL tried to change it back to rcn (with much better changeset
>>> comments :) - https://www.openstreetmap.org/changeset/12849599), but I
>>> guess he gave up. Polyglot later seems to have mapped most of the other
>>> routes; my guess is he just went with lcn because that's how the others
>>> were mapped.
>>>
>>> Apart from the network not showing up when it should on some maps, it
>>> doesn't really matter much. However, bxl-forever is now mapping -actual-
>>> lcn routes in the Brussels region, operated by Anderlecht municipality.
>>> Example: https://www.openstreetmap.org/relation/11544325
>>> Putting both types of routes in the same level is just wrong IMHO.
>>>
>>> Can anyone provide some more context? Based on my own research, I'd
>>> suggest we simply retag all the regional operated routes from lcn to rcn.
>>>
>>> Best,
>>> Joost Schouppe
>>> ___
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>


-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [Talk-it] Google trekker

[Alessio Piccioli]

Ciao a tutti,

  non ho più seguito in dettaglio il discorso di Google ma il CAI Nazionale
sta con OSM!!! A breve rinnoveremo la convenzione e in questi anni sono
stati inseriti un sacco di percorsi in tutta Italia siamo a 70.000 Km se
non erro.

Detto questo l'idea dello StreetView sui sentieri potrebbe essere un
qualcosa che attrae nei prossimi anni ci sarebbe Mapillary ma anche li
andiamo su terreno scivoloso in termini di usabilità (licenze e diritti)
del dato.

E se ci inventassimo qualcosa che parte proprio dal popolo di OSM? (magari
mi sono perso un pochino e qualcosa già esiste?)

Un saluto a tutte e tutti!!

A.

Il giorno mer 2 set 2020 alle ore 14:45 Manuel  ha
scritto:

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


-- 
*Alessio Piccioli / *Amministratore unico
alessiopicci...@webmapp.it
www.webmapp.it
+39 328 53 60 803


P.Iva e CF 02266770508
CCIAA di Pisa n. 02266770508 del 01/08/2017
Capitale Sociale 10.000,00 €
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-GB] Pedestrian priority and highway=cycleway

[Robert Skedgell]

If iD really is prompting changing highway=cycleway->highway=footway
without preserving cycle access, we can expect to see cycle routing
becoming badly broken in a lot of places. Some of these edits were made
3 weeks ago and nothing like that appears to have been reported elsewhere.

There also appears to be no justification in the wiki for assuming that
highway=cycleway should not be used where pedestrians have priority,
unless I have missed it. In general, the GB assumption is that
pedestrians have priority on infrastructure shared with cyclists.

Personally, I don't really care whether the top level tag is cycleway or
footway, as long as routing, access and other physical characteristics
are correct.

In any case, my first presumption was carelessness, not malice. Breaking
cycle routing in this part of London is very unhelpful, particularly at
the start of the new school term.

On 03/09/2020 10:39, Tom Hughes wrote:
> I suspect that the real clue is in the changeset tags:
> 
>   resolved:outdated_tags:incomplete_tags=10
> 
> So the iD validator has presumably claimed that the tagging of
> those paths was "out of date" in some way and this was likely a
> misguided attempt to fix that.
> 
> Of course that was likely based on some rule in the validator
> that is trying push whatever daft path tagging the wiki is
> currently trying to promote...
> 
> Certainly I think a polite enquiry would have been a better first
> response than presuming malice.
> 
> Tom

[...]

>> In several places, the edited object no longer has a bicycle=* access
>> tag and segregated=no has been removed, which breaks cycle routing
>> through the path. I am unsure whether this is carelessness, or the
 
>> expression of an agenda which has no place in OSM. If the latter, this
>> is vandalism.
>>

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

Re: [Talk-hr] Fwd: Import zgrada u Zagrebu

[Janko Mihelić]

Što smo na kraju odlučili za tagove? Jel dobro ovo:

source:geometry=Zagrebačka infrastruktura prostornih podataka
source:geometry:dataset=Aerofotogrametrijsko i LiDAR snimanje 2012.
source:geometry:ref=234235 (ovo umjesto zzip_import_id)
source:geometry:date=2012-03-26

pon, 31. kol 2020. u 09:47 Hrvoje Bogner  napisao je:

> On 28. 08. 2020. 13:57, Janko Mihelić wrote:
>
> pet, 28. kol 2020. u 13:25 Hrvoje Bogner  napisao je:
>
>>
>> Također lidar NIJE 100% točan, za neke objekte je bolje editirati te
>> vektore da pašu na ZG DOF 2018.
>>
>
> Koliko bi novi LIDAR mogao biti precizniji? Jel moguće da je toliko bolji
> da ćemo sve iz 2012 pretvoriti u novi?
>
> Ili je veća šansa da ono što sad uvezemo, i malo popravimo po DOF 2018, da
> se neće više mijenjati još dugo.
>
>
> Ja neznam je li novi lidar snimak Zagreb uopće u planu, znam za RH ali to
> je nije iskoristivo za kuće i zgrade.
>
> Trebamo koristiti ono što imamo sad na raspolaganju, osim ako netko nema
> sigurnu potvrdu i vremenski termin kad će se pojaviti neki bolji i
> kvalitetniji podatci.
>
> Pozdrav, Hrvoje
>
___
Talk-hr mailing list
Talk-hr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-hr

Re: [Talk-GB] Pedestrian priority and highway=cycleway

[Mateusz Konieczny via Talk-GB]

3 wrz 2020, 11:58 od o...@live.co.uk:
> Would access=permissive or access:bicycle=permissive be sensible? Or is that 
> also mangling tagging conventions. I genuinely don’t know!
>
It would be bicycle tag, not access:bicycle___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Pedestrian priority and highway=cycleway

[Dave F via Talk-GB]

I think highway should be reverted to cycleway. There's a 
misunderstanding that highway=cycleway implies priority to bicycle 
riders, when it actually relates just to the number of transport modes 
which can use it. Bridleway equates to three modes: walkers, bikes & horses.


DaveF

On 03/09/2020 11:02, Robert Skedgell wrote:

Rather than reverting, I restored access and left the top-level
highway=* tag alone.

I only noticed these changes when plotting a route in Komoot and
noticing that I needed to create/drag a lot of extra waypoints in order
to get the expected behaviour. Hopefully Komoot will behave responsibly
and warn me that I'll need to dismount in a few places. Repairing
routing as quickly as possible was my priority, although it could take
weeks for some routers to restore functionality.

In this case, I think that if there is any tagging for the renderer, the
target renderer was OpenCycleMap rather than OSM Carto.

On 03/09/2020 10:40, Ken Kilfedder wrote:

These changes should be reverted in my view.

But I would note that the default map on osm.org does a poor job of 
communicating the difference between shared paths (like those in QEOP and 
elsewhere) and dedicated cycle lanes.  Both look like blue dashed lines.   They 
look indistinguishable. So an honest pedestrian mapper might easily jump to the 
wrong conclusion and make changes of the sort you've described below.

Perhaps the right way forward is to suggest changes to how osm.org displays 
shared ways - red dash for dedicated pedestrian, blue dash for dedicated 
cycleway and alternating for shared?   Maybe something to indicate priority?   
Without changes like this, I can see this sort of thing happening again.

---
https://hdyc.neis-one.org/?spiregrain
spiregrain_...@ksglp.org.uk

[...]


It also appears to be tagging for the renderer, as changing
cycleway->footway changes the path in OpenCycleMap from a blue dashed
line to a red dashed line.

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



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

Re: [Talk-GB] Pedestrian priority and highway=cycleway

[Robert Skedgell]

I think access=permissive could have unfortunate consequences for motor
vehicle routing, unless routers ignore highway=footway|cycleway anyway.

Some of these paths should probably have motor_vehicle=private added
(together with some gates and removable/rising bollards), as maintenance
and event vehicles do use them.

On 03/09/2020 10:58, Gareth L wrote:
> I think the permissive tag is due to it being yet another perceived public 
> space which is actually private, so there’s no public right of way.
> 
> Would access=permissive or access:bicycle=permissive be sensible? Or is that 
> also mangling tagging conventions. I genuinely don’t know!
> 
> Gareth
> 
>> On 3 Sep 2020, at 10:42, Frederik Ramm  wrote:
>>
>> Hi,
>>
>>> On 03.09.20 11:29, Robert Skedgell wrote:
>>> I believe the most appropriate base tagging, following the duck tagging
>>> principle for highway=*, for most of the paths in QEOP would be:
>>> highway=cycleway + segregated=no + bicycle=permissive + foot=permissive
>>
>> I think that highway=cycleway implies bicycle=yes so adding a
>> bicycle=permissive would be confusing?
>>
>> In my mental picture the combination highway=cycleway+foot=permissive
>> means: "This is a way made and intended for bicycles. But pedestrians
>> are also tolerated." - which might well be correct given that there
>> seems to be a lot of cycle-related infrastructure around.
>>
>> To be honest, given the rules you cite, I would be tempted to use
>> highway=footway+bicycle=yes OR the dreaded
>> highway=path+bicycle=yes+foot=yes - but I haven't seen how it looks on
>> the ground.
>>
>> Bye
>> Frederik
>>
>> -- 
>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> 


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

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

[pepilepi...@ovh.fr]

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


Bien reçu

JP

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


-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question.

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

Re: [Talk-GB] Pedestrian priority and highway=cycleway

[Robert Skedgell]

Rather than reverting, I restored access and left the top-level
highway=* tag alone.

I only noticed these changes when plotting a route in Komoot and
noticing that I needed to create/drag a lot of extra waypoints in order
to get the expected behaviour. Hopefully Komoot will behave responsibly
and warn me that I'll need to dismount in a few places. Repairing
routing as quickly as possible was my priority, although it could take
weeks for some routers to restore functionality.

In this case, I think that if there is any tagging for the renderer, the
target renderer was OpenCycleMap rather than OSM Carto.

On 03/09/2020 10:40, Ken Kilfedder wrote:
> These changes should be reverted in my view.
> 
> But I would note that the default map on osm.org does a poor job of 
> communicating the difference between shared paths (like those in QEOP and 
> elsewhere) and dedicated cycle lanes.  Both look like blue dashed lines.   
> They look indistinguishable. So an honest pedestrian mapper might easily jump 
> to the wrong conclusion and make changes of the sort you've described below.
> 
> Perhaps the right way forward is to suggest changes to how osm.org displays 
> shared ways - red dash for dedicated pedestrian, blue dash for dedicated 
> cycleway and alternating for shared?   Maybe something to indicate priority?  
>  Without changes like this, I can see this sort of thing happening again.
> 
> ---
> https://hdyc.neis-one.org/?spiregrain
> spiregrain_...@ksglp.org.uk

[...]

>>
>> It also appears to be tagging for the renderer, as changing
>> cycleway->footway changes the path in OpenCycleMap from a blue dashed
>> line to a red dashed line.

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

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

[pepilepi...@ovh.fr]

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. 

Bonjour,

Bien reçu normalement.

Bonne journée,

JP

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


-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question.

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

Re: [Talk-GB] Pedestrian priority and highway=cycleway

[Gareth L]

I think the permissive tag is due to it being yet another perceived public 
space which is actually private, so there’s no public right of way.

Would access=permissive or access:bicycle=permissive be sensible? Or is that 
also mangling tagging conventions. I genuinely don’t know!

Gareth

> On 3 Sep 2020, at 10:42, Frederik Ramm  wrote:
> 
> Hi,
> 
>> On 03.09.20 11:29, Robert Skedgell wrote:
>> I believe the most appropriate base tagging, following the duck tagging
>> principle for highway=*, for most of the paths in QEOP would be:
>> highway=cycleway + segregated=no + bicycle=permissive + foot=permissive
> 
> I think that highway=cycleway implies bicycle=yes so adding a
> bicycle=permissive would be confusing?
> 
> In my mental picture the combination highway=cycleway+foot=permissive
> means: "This is a way made and intended for bicycles. But pedestrians
> are also tolerated." - which might well be correct given that there
> seems to be a lot of cycle-related infrastructure around.
> 
> To be honest, given the rules you cite, I would be tempted to use
> highway=footway+bicycle=yes OR the dreaded
> highway=path+bicycle=yes+foot=yes - but I haven't seen how it looks on
> the ground.
> 
> Bye
> Frederik
> 
> -- 
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Pedestrian priority and highway=cycleway

[Robert Skedgell]

On 03/09/2020 10:41, Frederik Ramm wrote:
> Hi,
> 
> On 03.09.20 11:29, Robert Skedgell wrote:
>> I believe the most appropriate base tagging, following the duck tagging
>> principle for highway=*, for most of the paths in QEOP would be:
>> highway=cycleway + segregated=no + bicycle=permissive + foot=permissive
> 
> I think that highway=cycleway implies bicycle=yes so adding a
> bicycle=permissive would be confusing?
> 
> In my mental picture the combination highway=cycleway+foot=permissive
> means: "This is a way made and intended for bicycles. But pedestrians
> are also tolerated." - which might well be correct given that there
> seems to be a lot of cycle-related infrastructure around.
> 
> To be honest, given the rules you cite, I would be tempted to use
> highway=footway+bicycle=yes OR the dreaded
> highway=path+bicycle=yes+foot=yes - but I haven't seen how it looks on
> the ground.
> 
> Bye
> Frederik
> 

The rationale for using permissive here is that there isn't really any
right of way through the park, so the park's operators can and do close
parts of it with little or no notice for events and maintenance.
Otherwise, I would probably be more inclined to use highway=cycleway +
segregated=no.


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

Re: [Talk-GB] Pedestrian priority and highway=cycleway

[Dan S]

Hi there,

Unless there's a "history" to this I recommend that you assume good
intent. Seems Skyguy made an embarrassing mistake there.

Please also don't assume "tagging for the renderer" or "vandalism",
those two OSM curse words ;) the mapper explicitly stated their
intention in the changeset comment, and it appears to be motivated by
the genuine status of the park.

By the way, the Olympic Park is technically private property not
public land, so local rules set by the park owner might take
precedence over generic Highway Code.

Best
Dan

Op do 3 sep. 2020 om 10:30 schreef Robert Skedgell :
>
> A user has recently changed highway=cycleway objects in Queen Elizabeth
> Olympic Park, London (QEOP) from highway=cycleway to highway=footway on
> the ground that "Olympic Park paths are Pedestrian Priority".
>
> In several places, the edited object no longer has a bicycle=* access
> tag and segregated=no has been removed, which breaks cycle routing
> through the path. I am unsure whether this is carelessness, or the
> expression of an agenda which has no place in OSM. If the latter, this
> is vandalism.
>
> It also appears to be tagging for the renderer, as changing
> cycleway->footway changes the path in OpenCycleMap from a blue dashed
> line to a red dashed line.
>
> Changes made by Skyguy in:
> https://www.openstreetmap.org/changeset/89374106
>
> Broken routing by missing access tags (not changing the highway=* tag
> for now) fixed in:
> https://www.openstreetmap.org/changeset/90351366
>
> Most paths in QEOP are 3 metre wide gold-top asphalt (looks a bit like
> surface=compacted and sometimes mapped as such) and there are no paths
> on which cycling is prohibited. The paths are almost all included as
> cycle tracks in the TfL CID export. QEOP is generally open to the public
> 24/7, but any part can be closed without notice for events.
>
> I believe the most appropriate base tagging, following the duck tagging
> principle for highway=*, for most of the paths in QEOP would be:
> highway=cycleway + segregated=no + bicycle=permissive + foot=permissive
>
> There is nothing in the Wiki which suggests that pedestrians do not
> already have priority on unsegregated cycleways, so the edit seems
> unnecessary.
>
> The current Highway Code Rule 62 does not make this explicit, but
> pedestrian priority seems a reasonable interpretation of: "Take care
> when passing pedestrians, especially children, older or disabled people,
> and allow them plenty of room. Always be prepared to slow down and stop
> if necessary."
> https://www.gov.uk/guidance/the-highway-code/rules-for-cyclists-59-to-82
>
> The proposed new Rule 63 could also reasonably be read as strongly
> implying pedestrian priority:
> "Sharing space with pedestrians, horse riders and horse drawn vehicles.
> When riding in places where sharing with pedestrians, horse riders or
> horse drawn vehicles is permitted take care when passing pedestrians,
> especially children, older adults or disabled people. Let them know you
> are there when necessary e.g. by ringing your bell (it is recommended
> that a bell is fitted to your bike), or by calling out politely.
> Remember that pedestrians may be deaf, blind or partially sighted and
> that this may not be obvious.
> Do not pass pedestrians, horse riders or horse drawn vehicles closely or
> at high speed, particularly from behind. Remember that horses can be
> startled if passed without warning. Always be prepared to slow down and
> stop when necessary."
> https://www.gov.uk/government/consultations/review-of-the-highway-code-to-improve-road-safety-for-cyclists-pedestrians-and-horse-riders/summary-of-the-consultation-proposals-on-a-review-of-the-highway-code
>
> BCC to DWG because of the impact in cycle routing.
>
> --
> Robert Skedgell (rskedgell)
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [Talk-GB] Pedestrian priority and highway=cycleway

[Frederik Ramm]

Hi,

On 03.09.20 11:29, Robert Skedgell wrote:
> I believe the most appropriate base tagging, following the duck tagging
> principle for highway=*, for most of the paths in QEOP would be:
> highway=cycleway + segregated=no + bicycle=permissive + foot=permissive

I think that highway=cycleway implies bicycle=yes so adding a
bicycle=permissive would be confusing?

In my mental picture the combination highway=cycleway+foot=permissive
means: "This is a way made and intended for bicycles. But pedestrians
are also tolerated." - which might well be correct given that there
seems to be a lot of cycle-related infrastructure around.

To be honest, given the rules you cite, I would be tempted to use
highway=footway+bicycle=yes OR the dreaded
highway=path+bicycle=yes+foot=yes - but I haven't seen how it looks on
the ground.

Bye
Frederik

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

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

Re: [Talk-GB] Pedestrian priority and highway=cycleway

[Ken Kilfedder]

These changes should be reverted in my view.

But I would note that the default map on osm.org does a poor job of 
communicating the difference between shared paths (like those in QEOP and 
elsewhere) and dedicated cycle lanes.  Both look like blue dashed lines.   They 
look indistinguishable. So an honest pedestrian mapper might easily jump to the 
wrong conclusion and make changes of the sort you've described below.

Perhaps the right way forward is to suggest changes to how osm.org displays 
shared ways - red dash for dedicated pedestrian, blue dash for dedicated 
cycleway and alternating for shared?   Maybe something to indicate priority?   
Without changes like this, I can see this sort of thing happening again.

---
https://hdyc.neis-one.org/?spiregrain
spiregrain_...@ksglp.org.uk

On Thu, 3 Sep 2020, at 10:29 AM, Robert Skedgell wrote:
> A user has recently changed highway=cycleway objects in Queen Elizabeth
> Olympic Park, London (QEOP) from highway=cycleway to highway=footway on
> the ground that "Olympic Park paths are Pedestrian Priority".
> 
> In several places, the edited object no longer has a bicycle=* access
> tag and segregated=no has been removed, which breaks cycle routing
> through the path. I am unsure whether this is carelessness, or the
> expression of an agenda which has no place in OSM. If the latter, this
> is vandalism.
> 
> It also appears to be tagging for the renderer, as changing
> cycleway->footway changes the path in OpenCycleMap from a blue dashed
> line to a red dashed line.
> 
> Changes made by Skyguy in:
> https://www.openstreetmap.org/changeset/89374106
> 
> Broken routing by missing access tags (not changing the highway=* tag
> for now) fixed in:
> https://www.openstreetmap.org/changeset/90351366
> 
> Most paths in QEOP are 3 metre wide gold-top asphalt (looks a bit like
> surface=compacted and sometimes mapped as such) and there are no paths
> on which cycling is prohibited. The paths are almost all included as
> cycle tracks in the TfL CID export. QEOP is generally open to the public
> 24/7, but any part can be closed without notice for events.
> 
> I believe the most appropriate base tagging, following the duck tagging
> principle for highway=*, for most of the paths in QEOP would be:
> highway=cycleway + segregated=no + bicycle=permissive + foot=permissive
> 
> There is nothing in the Wiki which suggests that pedestrians do not
> already have priority on unsegregated cycleways, so the edit seems
> unnecessary.
> 
> The current Highway Code Rule 62 does not make this explicit, but
> pedestrian priority seems a reasonable interpretation of: "Take care
> when passing pedestrians, especially children, older or disabled people,
> and allow them plenty of room. Always be prepared to slow down and stop
> if necessary."
> https://www.gov.uk/guidance/the-highway-code/rules-for-cyclists-59-to-82
> 
> The proposed new Rule 63 could also reasonably be read as strongly
> implying pedestrian priority:
> "Sharing space with pedestrians, horse riders and horse drawn vehicles.
> When riding in places where sharing with pedestrians, horse riders or
> horse drawn vehicles is permitted take care when passing pedestrians,
> especially children, older adults or disabled people. Let them know you
> are there when necessary e.g. by ringing your bell (it is recommended
> that a bell is fitted to your bike), or by calling out politely.
> Remember that pedestrians may be deaf, blind or partially sighted and
> that this may not be obvious.
> Do not pass pedestrians, horse riders or horse drawn vehicles closely or
> at high speed, particularly from behind. Remember that horses can be
> startled if passed without warning. Always be prepared to slow down and
> stop when necessary."
> https://www.gov.uk/government/consultations/review-of-the-highway-code-to-improve-road-safety-for-cyclists-pedestrians-and-horse-riders/summary-of-the-consultation-proposals-on-a-review-of-the-highway-code
> 
> BCC to DWG because of the impact in cycle routing.
> 
> -- 
> Robert Skedgell (rskedgell)
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>

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

Re: [Talk-GB] Pedestrian priority and highway=cycleway

[Tom Hughes via Talk-GB]

I suspect that the real clue is in the changeset tags:

  resolved:outdated_tags:incomplete_tags=10

So the iD validator has presumably claimed that the tagging of
those paths was "out of date" in some way and this was likely a
misguided attempt to fix that.

Of course that was likely based on some rule in the validator
that is trying push whatever daft path tagging the wiki is
currently trying to promote...

Certainly I think a polite enquiry would have been a better first
response than presuming malice.

Tom

On 03/09/2020 10:29, Robert Skedgell wrote:

A user has recently changed highway=cycleway objects in Queen Elizabeth
Olympic Park, London (QEOP) from highway=cycleway to highway=footway on
the ground that "Olympic Park paths are Pedestrian Priority".

In several places, the edited object no longer has a bicycle=* access
tag and segregated=no has been removed, which breaks cycle routing
through the path. I am unsure whether this is carelessness, or the
expression of an agenda which has no place in OSM. If the latter, this
is vandalism.

It also appears to be tagging for the renderer, as changing
cycleway->footway changes the path in OpenCycleMap from a blue dashed
line to a red dashed line.

Changes made by Skyguy in:
https://www.openstreetmap.org/changeset/89374106

Broken routing by missing access tags (not changing the highway=* tag
for now) fixed in:
https://www.openstreetmap.org/changeset/90351366

Most paths in QEOP are 3 metre wide gold-top asphalt (looks a bit like
surface=compacted and sometimes mapped as such) and there are no paths
on which cycling is prohibited. The paths are almost all included as
cycle tracks in the TfL CID export. QEOP is generally open to the public
24/7, but any part can be closed without notice for events.

I believe the most appropriate base tagging, following the duck tagging
principle for highway=*, for most of the paths in QEOP would be:
highway=cycleway + segregated=no + bicycle=permissive + foot=permissive

There is nothing in the Wiki which suggests that pedestrians do not
already have priority on unsegregated cycleways, so the edit seems
unnecessary.

The current Highway Code Rule 62 does not make this explicit, but
pedestrian priority seems a reasonable interpretation of: "Take care
when passing pedestrians, especially children, older or disabled people,
and allow them plenty of room. Always be prepared to slow down and stop
if necessary."
https://www.gov.uk/guidance/the-highway-code/rules-for-cyclists-59-to-82

The proposed new Rule 63 could also reasonably be read as strongly
implying pedestrian priority:
"Sharing space with pedestrians, horse riders and horse drawn vehicles.
When riding in places where sharing with pedestrians, horse riders or
horse drawn vehicles is permitted take care when passing pedestrians,
especially children, older adults or disabled people. Let them know you
are there when necessary e.g. by ringing your bell (it is recommended
that a bell is fitted to your bike), or by calling out politely.
Remember that pedestrians may be deaf, blind or partially sighted and
that this may not be obvious.
Do not pass pedestrians, horse riders or horse drawn vehicles closely or
at high speed, particularly from behind. Remember that horses can be
startled if passed without warning. Always be prepared to slow down and
stop when necessary."
https://www.gov.uk/government/consultations/review-of-the-highway-code-to-improve-road-safety-for-cyclists-pedestrians-and-horse-riders/summary-of-the-consultation-proposals-on-a-review-of-the-highway-code

BCC to DWG because of the impact in cycle routing.




--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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

[Talk-GB] Pedestrian priority and highway=cycleway

[Robert Skedgell]

A user has recently changed highway=cycleway objects in Queen Elizabeth
Olympic Park, London (QEOP) from highway=cycleway to highway=footway on
the ground that "Olympic Park paths are Pedestrian Priority".

In several places, the edited object no longer has a bicycle=* access
tag and segregated=no has been removed, which breaks cycle routing
through the path. I am unsure whether this is carelessness, or the
expression of an agenda which has no place in OSM. If the latter, this
is vandalism.

It also appears to be tagging for the renderer, as changing
cycleway->footway changes the path in OpenCycleMap from a blue dashed
line to a red dashed line.

Changes made by Skyguy in:
https://www.openstreetmap.org/changeset/89374106

Broken routing by missing access tags (not changing the highway=* tag
for now) fixed in:
https://www.openstreetmap.org/changeset/90351366

Most paths in QEOP are 3 metre wide gold-top asphalt (looks a bit like
surface=compacted and sometimes mapped as such) and there are no paths
on which cycling is prohibited. The paths are almost all included as
cycle tracks in the TfL CID export. QEOP is generally open to the public
24/7, but any part can be closed without notice for events.

I believe the most appropriate base tagging, following the duck tagging
principle for highway=*, for most of the paths in QEOP would be:
highway=cycleway + segregated=no + bicycle=permissive + foot=permissive

There is nothing in the Wiki which suggests that pedestrians do not
already have priority on unsegregated cycleways, so the edit seems
unnecessary.

The current Highway Code Rule 62 does not make this explicit, but
pedestrian priority seems a reasonable interpretation of: "Take care
when passing pedestrians, especially children, older or disabled people,
and allow them plenty of room. Always be prepared to slow down and stop
if necessary."
https://www.gov.uk/guidance/the-highway-code/rules-for-cyclists-59-to-82

The proposed new Rule 63 could also reasonably be read as strongly
implying pedestrian priority:
"Sharing space with pedestrians, horse riders and horse drawn vehicles.
When riding in places where sharing with pedestrians, horse riders or
horse drawn vehicles is permitted take care when passing pedestrians,
especially children, older adults or disabled people. Let them know you
are there when necessary e.g. by ringing your bell (it is recommended
that a bell is fitted to your bike), or by calling out politely.
Remember that pedestrians may be deaf, blind or partially sighted and
that this may not be obvious.
Do not pass pedestrians, horse riders or horse drawn vehicles closely or
at high speed, particularly from behind. Remember that horses can be
startled if passed without warning. Always be prepared to slow down and
stop when necessary."
https://www.gov.uk/government/consultations/review-of-the-highway-code-to-improve-road-safety-for-cyclists-pedestrians-and-horse-riders/summary-of-the-consultation-proposals-on-a-review-of-the-highway-code

BCC to DWG because of the impact in cycle routing.

-- 
Robert Skedgell (rskedgell)

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

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

[Sebastian S.]

Hi,
I have made excessive use of the node tag for islands.
Particularly for pedestrian crossing.

Splitting the road into two separate ways for only a few metres seems excessive 
to me. Even when there is a several Meter long raised kerb separating the lanes 
I would not split the road.




On 1 September 2020 10:05:42 pm AEST, Andrew Harvey  
wrote:
>Heads up, looks like their team has started to map in Perth, see on
>OSMCha
>-> https://osmcha.org/?aoi=80b50a6d-6bb5-48cb-8ac4-4b2ddd9d5d76
>
>Mostly looks okay to me, and mostly minor tweaks, though I raised a few
>questions and issues on changeset comments but also listed most of them
>here:
>
>https://www.openstreetmap.org/way/840589945/history was added but the
>existing road name and other applicable attributes were not applied.
>This
>same issue happens in quite a few other places too so appears to be
>systemic. I've raised some changeset comments but worth including this
>as
>part of the standard practice by your editing team.
>
>https://www.openstreetmap.org/way/842851495/history is that a
>roundabout? I
>can't tell from the Maxar imagery, yet that is the claimed source, how
>could you tell from the imagery what this is?
>
>I personally find splitting ways for a traffic island at roundabouts
>like
>in https://www.openstreetmap.org/way/840189281/history a tad to
>excessive
>(would prefer to just tag the node as traffic island and use one way,
>gives
>a much cleaner dataset as the transition between dual and single
>carriageways is always messy) but I guess it's not wrong and both
>styles
>are popular in OSM currently. Does the community have a view on this?
>
>Unclear source of the turn restriction in
>https://www.openstreetmap.org/changeset/90223764#map=18/-32.04553/115.80953
>
>On Sun, 16 Aug 2020 at 21:28, OSM NextBillion. AI 
>wrote:
>
>> Thank you cleary for valuable insights, we would be more cautious
>while
>> mapping in such areas. While Satellite Imagery is our prime resource,
>we’d
>> consider mapillary photos as well wherever available. We do have some
>> expert assistance in our team for interpreting satellite imagery and
>map
>> something only if we’re double sure of it’s existence. We will refer
>to
>> mappers history before editing existing data to understand if it was
>> created using local expertise and would change only if there is
>conclusive
>> evidence from satellite and mapillary imageries.
>>
>> We will reach out to local mapping experts through forum and/or
>changeset
>> comments if we require further help.
>>
>> Thank you all once again for the suggestions, we look forward to
>working
>> with you all. :)
>>
>>
>> On Sun, 16 Aug 2020 at 05:35, cleary  wrote:
>>
>>>
>>> Thanks for the interest in mapping in Australia and thanks for
>posting
>>> your plans on this list.
>>>
>>> I would add to the caution expressed by others.  I live in an urban
>>> location in Australia but I have travelled in other areas within
>>> Australia.  It has taken me quite some time to learn to interpret
>satellite
>>> imagery and I still have a lot to learn about this country.  After
>>> personally visiting areas and noting what I see, and sometimes
>taking
>>> photographs, I then return home and compare my notes with what I see
>in the
>>> imagery and I am still surprised.  I think it can be quite
>precarious to
>>> map features using just satellite imagery unless you have expert
>assistance
>>> in interpreting the imagery.  For example, a common error by others
>has
>>> been to map lines of cleared vegetation as roads when they are
>actually
>>> fences. Even where an unmapped road exists, it is probably still
>unmapped
>>> because it is a private road and not accessible by the public - many
>of the
>>> roads on rural properties in Australia are private and, if added to
>the
>>> map, need to marked as such. Farmers get annoyed about intruders on
>their
>>> farms especially as biosecurity is a significant concern in parts of
>>> Australia.
>>>
>>> So while I appreciate contributions to the map, I suggest that
>"armchair"
>>> mapping needs to be undertaken with a lot of caution.
>>>
>>>
>>>
>>>
>>> On Sat, 15 Aug 2020, at 2:17 AM, OSM NextBillion. AI wrote:
>>> > Hi all,
>>> >
>>> >
>>> >
>>> > We’re a small team based out of Hyderabad, India. We would be
>doing
>>> > minimal edits in Perth and contribute to OSM in the next couple of
>>> > weeks, in-line with OSM and Australia specific tagging guidelines
>[Link
>>> >
>].
>>> >
>>> >
>>> > Please refer our Wiki
>>> >  and
>Github
>>> >  project pages
>for
>>> > more information.
>>> >
>>> > Looking forward to suggestions, if any ☺
>>> >
>>> > Thanking you in advance,
>>> > Team NextBillion
>>> > ___
>>> > Talk-au mailing list
>>> > Talk-au@openstreetmap.org
>>> > 

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

[Frederik Ramm]

Thanks all,

I've made the change on OSM and informed the complainant.

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-be] regional cycle routes in Brussels

[Jo]

I had a look at them after downloading them using Overpass API and started
making them continuous where they were 'broken'. So I went ahead and also
converted them all to rcn.

Jo

On Thu, Sep 3, 2020 at 9:41 AM Jo  wrote:

> Hi Joost,
>
> In Flanders it depended more on topology than anything else. We used:
>
> lcn: for loops
> rcn: for the numbered node networks, this logic was taken to rwn and rhn
> later on
> ncn: for long routes going from A to B (LFx) and then later for the Fxxx
> cycle highways
> icn: for European routes going from A to B
>
> In Brussels rcn doesn't seem to be used and those routes are topologically
> more similar to the numbered routes system used in Flanders and Wallonia.
>
> I agree with you that it makes more sense to tag them as rcn.
>
> Jo
>
> On Thu, Sep 3, 2020 at 9:14 AM joost schouppe 
> wrote:
>
>> Hi,
>>
>> I was always a little confused that the regional cycle network is mapped
>> as lcn in Brussels. Since this network is organized by Brussels-the-region,
>> not Brussels-the-city, it seems logical that it should have the rcn tag. In
>> fact, more so than the Flemish cycle node network, which is composed of
>> several networks and almost by coincidence covers the region.
>>
>> This is also what we say in the wiki:
>>
>> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycle_Routes#Itin.C3.A9raires_Cyclables_R.C3.A9gionaux_-_Gewestelijke_Fietsroute
>>
>> But the example given there (https://www.openstreetmap.org/relation/9623
>> I believe), is now mapped as an lcn.
>>
>> Looking at the edit history, it looks like there was a minor edit war
>> about this, where user RoRay repeatedly changed it from rcn to lcn
>> https://www.openstreetmap.org/changeset/8141976
>> https://www.openstreetmap.org/changeset/12902663
>> (RoRay is still mapping, still using the not-very helpful default
>> changeset description "update")
>>
>> User BenoitL tried to change it back to rcn (with much better changeset
>> comments :) - https://www.openstreetmap.org/changeset/12849599), but I
>> guess he gave up. Polyglot later seems to have mapped most of the other
>> routes; my guess is he just went with lcn because that's how the others
>> were mapped.
>>
>> Apart from the network not showing up when it should on some maps, it
>> doesn't really matter much. However, bxl-forever is now mapping -actual-
>> lcn routes in the Brussels region, operated by Anderlecht municipality.
>> Example: https://www.openstreetmap.org/relation/11544325
>> Putting both types of routes in the same level is just wrong IMHO.
>>
>> Can anyone provide some more context? Based on my own research, I'd
>> suggest we simply retag all the regional operated routes from lcn to rcn.
>>
>> Best,
>> Joost Schouppe
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] regional cycle routes in Brussels

[Jo]

Hi Joost,

In Flanders it depended more on topology than anything else. We used:

lcn: for loops
rcn: for the numbered node networks, this logic was taken to rwn and rhn
later on
ncn: for long routes going from A to B (LFx) and then later for the Fxxx
cycle highways
icn: for European routes going from A to B

In Brussels rcn doesn't seem to be used and those routes are topologically
more similar to the numbered routes system used in Flanders and Wallonia.

I agree with you that it makes more sense to tag them as rcn.

Jo

On Thu, Sep 3, 2020 at 9:14 AM joost schouppe 
wrote:

> Hi,
>
> I was always a little confused that the regional cycle network is mapped
> as lcn in Brussels. Since this network is organized by Brussels-the-region,
> not Brussels-the-city, it seems logical that it should have the rcn tag. In
> fact, more so than the Flemish cycle node network, which is composed of
> several networks and almost by coincidence covers the region.
>
> This is also what we say in the wiki:
>
> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycle_Routes#Itin.C3.A9raires_Cyclables_R.C3.A9gionaux_-_Gewestelijke_Fietsroute
>
> But the example given there (https://www.openstreetmap.org/relation/9623
> I believe), is now mapped as an lcn.
>
> Looking at the edit history, it looks like there was a minor edit war
> about this, where user RoRay repeatedly changed it from rcn to lcn
> https://www.openstreetmap.org/changeset/8141976
> https://www.openstreetmap.org/changeset/12902663
> (RoRay is still mapping, still using the not-very helpful default
> changeset description "update")
>
> User BenoitL tried to change it back to rcn (with much better changeset
> comments :) - https://www.openstreetmap.org/changeset/12849599), but I
> guess he gave up. Polyglot later seems to have mapped most of the other
> routes; my guess is he just went with lcn because that's how the others
> were mapped.
>
> Apart from the network not showing up when it should on some maps, it
> doesn't really matter much. However, bxl-forever is now mapping -actual-
> lcn routes in the Brussels region, operated by Anderlecht municipality.
> Example: https://www.openstreetmap.org/relation/11544325
> Putting both types of routes in the same level is just wrong IMHO.
>
> Can anyone provide some more context? Based on my own research, I'd
> suggest we simply retag all the regional operated routes from lcn to rcn.
>
> Best,
> Joost Schouppe
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[talk-cz] WeeklyOSM CZ 525

[Tom Ka]

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

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

* Fody z terénu.
* Obdělávané cesty.
* Mapování rozhleden.
* OpenStreetCam a starý mobil.
* Konfliktní přístupy.
* Jak (ne)hlasovat pro tagy.
* MapRoulette v srpnu.
* OSM bez jmen.
* Financování editoru iD.
* HOT a COVID-19.
* 10. výročí HOT.
* 16. let OSM.
* Okruh 5km v Melbourne.
* Hory na Tchaj-wanu.
* Požáry v Portugalsku.
* Navigace bez GPS.

Pěkné počtení ...

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

[OSM-talk-be] regional cycle routes in Brussels

[joost schouppe]

Hi,

I was always a little confused that the regional cycle network is mapped as
lcn in Brussels. Since this network is organized by Brussels-the-region,
not Brussels-the-city, it seems logical that it should have the rcn tag. In
fact, more so than the Flemish cycle node network, which is composed of
several networks and almost by coincidence covers the region.

This is also what we say in the wiki:
https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycle_Routes#Itin.C3.A9raires_Cyclables_R.C3.A9gionaux_-_Gewestelijke_Fietsroute

But the example given there (https://www.openstreetmap.org/relation/9623 I
believe), is now mapped as an lcn.

Looking at the edit history, it looks like there was a minor edit war about
this, where user RoRay repeatedly changed it from rcn to lcn
https://www.openstreetmap.org/changeset/8141976
https://www.openstreetmap.org/changeset/12902663
(RoRay is still mapping, still using the not-very helpful default changeset
description "update")

User BenoitL tried to change it back to rcn (with much better changeset
comments :) - https://www.openstreetmap.org/changeset/12849599), but I
guess he gave up. Polyglot later seems to have mapped most of the other
routes; my guess is he just went with lcn because that's how the others
were mapped.

Apart from the network not showing up when it should on some maps, it
doesn't really matter much. However, bxl-forever is now mapping -actual-
lcn routes in the Brussels region, operated by Anderlecht municipality.
Example: https://www.openstreetmap.org/relation/11544325
Putting both types of routes in the same level is just wrong IMHO.

Can anyone provide some more context? Based on my own research, I'd suggest
we simply retag all the regional operated routes from lcn to rcn.

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

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

[Denis Chenu via Talk-fr]

Bonjour,

Je trouve bizarre et malvenu de changer l'expéditeur.

Je laisse (comme tous le monde ici) l'expéditeur réel, je ne le modifie
pas pour passer en talk-fr …
De plus , le jour ou openstreetmap.org ajouteras du DKIM/SPF et consort
: ton mail sera refusé par les serveurs sérieux.

Sinon : mail 1 & 2 reçus.

Denis

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

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

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

[Bart Vanherck]

In Geel there is also a Fietszone in the centre. I will update it later on
too. I still have to check where the boundaries are. They are not in
complete streets so have to verify it manually.

Op zo 30 aug. 2020 om 14:50 schreef Jo :

> Hi,
>
> I added the new fietsstraatzones in Leuven to the map. They will be in
> vigor on September 1st. The legislator didn't create a separate sign, they
> just decided that it's allowed use F111 on a ZONE sign...
>
> I do like to distinguish between the 'real' cycle streets and the
> 'pretenders', so the ones inside zones and the ones connecting the zones, I
> guess. I used BE:F111zone as the traffic_sign. I may have done something
> silly though, as I removed the F4a from the traffic sign tag.
>
> If you search for F111 you get all.
> If you search for F111zone you get all the ones inside the zones.
> If you search for "F111 -F111zone" in JOSM, you get only the cyclestreets
> with an actual cycle street sign.
>
> If you search for F4a you get all the streets inside the zone30, but the
> cycle streets are not included in that. How do we want to work with zones
> within zones? There are also parking zones...
>
> Should I have put traffic_sign=BE:F111;BE:F4a;BE:F1a ?
>
> Initially I didn't because both are limited to 30km/h, but now I'm
> thinking I should have.
>
> What about the living_street ways? They are also inside the zone30 (and in
> built-up area), but the traffic rules that apply are BE:F12a. Do we add
> BE:F12a;BE:F4a;BE:F1a ?
>
> Jo
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be