date:20180829


On 29/08/2018 20:32, Toby Speight wrote:


I consider it a "niche" that wants them hidden.


The vast, vast majority are hidden on the ground.


  I don't see
that we have to mis-tag them all to have them hidden - I can see it
would be useful to have a map with less clutter, but it shouldn't be
hard to do that without having to mangle the underlying OSM database!


Separating tags isn't "mangling" It makes the database more detailed & 
accurate.


How would you propose to do it?


Yes, I appreciate that if the highways_authority_ref were documented and
somehow agreed to be correct, then for mkgmap it would be a simple
matter of "add ref ${highways_authority_ref};" near the beginning; it
would be a bit harder to get a workable tag template for Merkaartor, but
tools like KeepRight and Geofabrik QA aren't so easily adjusted, and
unlikely to adopt new tagging until it's at least documented.


I'm sorry, but this is poppycock. All data users should have ability to 
responded to changes in the database. The tail does not wag the dog.


DaveF

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

Re: [Talk-GB] GB does not include Northern Ireland


On 29/08/2018 20:35, Toby Speight wrote:

Wou> ... GB doesn't include Northern Ireland, ...

Even in these days of Brexit, I don't think there's any movement for
Northern Ireland to leave GB.  You've been misinformed!

Sorry Toby, but it's you who's been misinformed.

https://en.wikipedia.org/wiki/Great_Britain

DaveF

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

Re: [talk-au] Unmarked tracks (Figure of Eight Pools, NSW)

2018-08-29 Per discussione Phil Wyatt

Given the level of publicity/invitation of the area I think its fair to have it 
on the map. It would be worth adding some warning/risk information if possible 
given concern for walkers in the area

 

https://www.nationalparks.nsw.gov.au/things-to-do/lookouts/figure-eight-pools

 

Cheers - Phil

 

From: Andrew Harvey [mailto:andrew.harv...@gmail.com] 
Sent: Wednesday, 29 August 2018 11:28 PM
To: OSM Australian Talk List
Subject: [talk-au] Unmarked tracks (Figure of Eight Pools, NSW)

 

I'm seeking some feedback from the community about the way at 
https://osmlab.github.io/osm-deep-history/#/way/157934548 should it exist in 
OSM?

 

https://www.flickr.com/photos/136319147@N08/22832546277/in/datetaken-public/

 

There isn't really any marked track on the ground, which is a big reason to not 
include, however it is a path in the sense that it's a way that people follow 
pretty much every day or at least every weekend in droves, it just hasn't 
formed a track that you can see like other bush tracks because shoes don't ware 
away bear rock that fast compared to dirt! It's verifiable and surveyable by 
observing people follow the path. The fact that it's unmarked is recorded by 
trail_visibility=no (a documented and used tag) and that it's over rock by the 
surface tag.

I'm vocal about not tagging for the renderer or routed, but from a map 
rendering and routing perspective it's desired to have this way in OSM.

 

Thoughts?

 

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

Re: [Talk-ca] Fwd: Données GTFS et licence d'utilisation

2018-08-29 Per discussione Damien Riegel

Bonjour Claude,


Effectivement, si les données sont disponibles sous licence CC-BY, il
faudra obtenir une autorisation. Au cas où, je mets un lien vers un article
(en anglais) qui explique pourquoi il faut faire ça et comment le faire:
https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/

En ce qui concerne l'import, il me semble que la logique d'OSM voudrait
qu'on préfère garder les stations qui sont déjà existantes plutôt que de
les remplacer (la logique étant qu'on préfère des données saisies par des
utilisateurs à des données issues d'imports). S'il n'y a qu'une vingtaine
d'arrêts problématiques, est-ce envisageable de ne pas les importer et de
garder les existants ? Je pense que la discussion concernant l'import peut
avoir lieu sur cette liste.

Marquer les arrêts comme highway=bus_stop n'est pas incompatible avec
Public Transport v2. J'ai ajouté ce tag pour des arrêts que j'ai ajouté à
Montréal car sinon ils ne sont pas affichés sur la carte, donc autant le
garder à mon avis. J'ai aussi vu qu'il y avait des discussions pour
retravailler le format Public Transport v2 avec une reintroduction de
highway=bus_stop.

J'en profite pour ajouter que pour Montréal, j'ai crée un tableau qui
recense l'état actuel du réseau de la STM dans OSM:
https://wiki.openstreetmap.org/wiki/Bus_routes_in_Montr%C3%A9al . Je ne
sais pas si ça vaut le coup d'ajouter EXO sur cette page ou de créer une
page dédiée, à voir.

Bonne soirée,
Damien

On Tue, 28 Aug 2018 at 15:21, Alouette955  wrote:

> Bonjour,
>
> J’étais à la veille d’écrire à cette liste pour le même sujet mais
> concernant le RTM (Réseau de transport métropolitain, maintenant EXO).
>
> Je crois que leur données ouvertes, sujettes à la licence CC-BY, me
> poseraient le même problème. Voir
> https://rtm.quebec/fr/a-propos/donnees-ouvertes. Auquel cas je ferai la
> même démarche auprès de donneesouvertes@exo.quebec.
>
> Si jamais un projet d’importation des données GTFS de Exo est déjà dans la
> moulinette merci de m’en informer.
>
> Mon projet est d’importer, dans un premier temps, les arrêts d’autobus
> (public_transport=platform) afin, dans un deuxième temps, de les intégrer
> manuellement dans des relations de lignes  et trajets d’autobus selon la
> norme  Public Transport version 2. J’étais sur le point de créer une page
> sur le Wiki pour discuter/avaliser cette importation.
>
> Pour ce faire je devrais effacer une vingtaine d’arrêts ajoutés
> manuellement au fil du temps qui arborent plutôt l’ancien attribut
> highway=bus_stop et ne correspondent qu’approximativement aux coordonnées
> lat/long de Exo.
>
> Si ce projet est en cours je proposerais mon aide sinon j’aimerais bien en
> discuter. Je sais que quelques lignes d’autobus à Laval ont été ajoutées et
> semblent se conformer partiellement à la norme v2.
>
> Malheureusement il n’existe pas de liste de discussions pour la banlieue
> de Montréal pour y lancer la discussion.
>
> Merci,
>
> Claude
>
> *From:* Damien Riegel
> *Sent:* Monday, August 27, 2018 8:49 PM
> *To:* talk-ca
> *Subject:* [Talk-ca] Fwd: Données GTFS et licence d'utilisation
>
>  English version below 
> Bonsoir à tous,
>
>
> J'avais contacté la STM en juillet concernant l'utilisation de leurs
> données GTFS dans OSM. Ils fournissent des données avec une license
> d'utilisation qui empeche l'import à cause de la clause de mention, il nous
> fallait donc une autorisation explicite pour pouvoir les utiliser. C'est
> maintenant chose faite !
>
> Je vous transfert le mail que j'ai reçu de leur part et vais mettre à jour
> le wiki pour ajouter la STM dans la page des contributeurs.
>
>  English version 
> Hi everyone,
>
> I wrote to the STM (Société de Transport de Montréal) in July about using
> their GTFS data for OSM. They provide data with a license that blocked us
> from using them because of an attribution clause, so we needed an explicit
> authorization to be able to use them. We just got it!
>
> I'm transfering their email (in french) and will update the wiki to add
> the STM on the Contributors page.
>
> Bonne soirée,
> Damien
>
> -- Forwarded message -
> From: Développeurs STM 
> Date: Wed, 22 Aug 2018 at 09:18
> Subject: RE: Données GTFS et licence d'utilisation
> To: Damien Riegel 
>
>
> Bonjour Damien,
>
>
>
> Désolé pour le délai de réponse.
>
>
>
> Oui, vous pouvez utiliser les données GTFS de la STM pour Open Street Map
> en ajoutant la Société de transport de Montréal dans la page des
> contributeurs.
>
>
>
> Nous analysons la façon de faire de la ville de Montréal quant à son
> accord explicite, il y a quelque chose d’intéressant.
>
>
>
> Merci et encore une fois désolé du délai de réponse.
>
>
>
> Bonne journée
>
>
>
> *Nicolas Bertrand*
>
> *Chargé de projets - Systèmes électroniques d'informationSociété de
> transport de Montréal*
> DE Expérience client et activités commerciales
>
>
>
> *De :* Damien Riegel [mailto:damien.rie...@gmail.com]
> *Envoyé :* 14 août 2018 19:19
> *À :*

Re: [Talk-GB] Road refs


On 29/08/2018 20:44, Toby Speight wrote:

0> In article ,
0> Dave F. mailto:davefoxfa...@btinternet.com> ("Dave") wrote:

Dave> Point about OSM wiki: IMO giving multiple options for the same
Dave> entity leads to confusion & errors so should be avoided.

That's exactly what's problematic about "highways_authority_ref": it
creates a tag that contains the same information as belongs in "ref".

Based on the name, the similarity to ncn_ref and the like suggests a
non-authoritative alternative identifier.


Hi Toby

Let's deal with the last point first. Unsure how you could describe 
'highways_authority_ref' as 'non-authoritative'.


'ncn_ref' isn't 'non-authoritative' or similar to it's a label given to 
an assigned highway by Sustrans, many miles of which are maintained by 
local authorities.


OK, main point: 'ref' was used almost from the start of OSM when Steve 
C. mapped the first ways. As the database evolved it became clear 'ref' 
was too ambiguous & so other 'ref' tags evolved. Please remember there 
were no focus groups meetings laying out a pathway concept. OSM is a 
truly organic development. Things change, evolve. As the database 
becomes more detailed so the tags become more detailed. Contributors 
should be expecting change & willing to adapt. Being fearful of change 
is not a reason for the status-quo.


I've used 'highways_authority_ref' as it was suggested as a more 
specific tag to the alternatives. As I said in my OP I'm wiling to amend 
that, but only after I've amalgamated all the relevant tags & someone 
comes up with a better alternative. So far no one has done so.


Getting all contributors to use 'highway_authority_ref' will be 
problematic, in *exactly* the same way it is for so many other tags. 
That is *not* a reason to not improve OSM's database.


General point to all: Others here & on private email appear to think I, 
& I alone, conceived this proposal. I did not. This is clearly evident 
from reading the links in my OP. If anyone wishes to criticize the 
proposal, please have the common decency to base it on facts & evidence.


Cheers
DaveF

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

Re: [OSM-talk-be] Opportuniteit voor OV mapper.

2018-08-29 Per discussione Jo

Oh, ik had die buslijnen al eens gemapt. Ja, fameuze verandering, geen 2,
2A en 2B meer. 2B ging naar België...

Komt er in LEFFRINCKOUCKE FORT DES DUNES een groter busstation?

Hmm, eens gaan kijken. Ik had alles mooi gemapt met nodes langs de weg.
sind februari 2018 heeft iemand dat compleet aangepast met nodes op de ways
en platform ways, ook al zijn er daar niet overal perrons langs die
kustweg, die voorstellen met een way is eigenlijk absurd.
Dus ik ga me daar niet mee bezig houden. Wat mij betreft een stap achteruit
om van 1 object per halte naar 2 te gaan.

Jo

Op wo 29 aug. 2018 om 22:47 schreef Marc Coevoet :

> Besten,
>
> Vanaf 1 sept verandert het OV van Duinkerke.  Er zal niet alleen een bus
> zijn om de 10' in het centrum, het schema van de stadsbedekking
> verandert totaal.
> En bovendien, de bus zal IEDERE dag GRATIS zijn. (al sinds een drietal
> jaar gratis in het weekend).
>
> Een kans dus voor een mapper, om de ganse dkbus.com te herschrijven in
> dkbus2018.com
>
>
> Marc
> PS: en wat heeft dat nu met Belgie te maken?  Wel de bus start oa in
> Adinkerke, aan het station.  Ipv ieder uur nu zowat om de 15' tot aan
> een groot knooppunt in Leffrinckoucke.
> --
> The "Penguin" has arrived - and he's not going away - ever.
> For former Apple users: Xubuntu.org (menu's up left)
> For former Windows users: Lubuntu.org (menu's down left)
>
> ___
> 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-GB] un-named roads in UK

2018-08-29 Per discussione Lester Caine


On 29/08/18 21:21, Jubal Harpster wrote:

Stadium Mews

https://www.openstreetmap.org/way/260127900

https://goo.gl/maps/JJNxamCgLy12

_https://binged.it/2C0LAw1_


PAF file ... N5 1FP

--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] Open Location Code and Graffiti

2018-08-29 Per discussione Pierre Béland

Mobile phones let geolocate pictures.  Why not simply send a geolocated 
pictures? This would document the graffiti at the same time. 

 
Pierre 
 

Le mercredi 29 août 2018 16 h 57 min 25 s HAE, john whelan 
 a écrit :  
 
 But what is needed to make it work?
Thanks John
On Wed, 29 Aug 2018, 3:59 pm Pine W,  wrote:

Thanks for sharing the idea of reporting problems like graffiti using 
coordinates. For some reason this idea never crossed my mind until I read your 
email. This would have been useful for me on one occasion in particular when I 
was trying to describe the location of graffiti in a public park. I can think 
of other types of situations where coordinates would be more useful than saying 
something like "200 feet north of the iron statue and on the west side of the 
gatehouse, above a path that goes to the creek".

Pine
( https://meta.wikimedia.org/wiki/User:Pine )

On Sat, Aug 25, 2018 at 10:06 PM john whelan  wrote:

It sounds an odd combination but locally you can report Graffiti to the 
municipality and they arrange for it to be cleaned up by the phone company, 
electric company etc.
The targeted electric boxes are often at the back of houses or on stretches of 
highway that have no houses which means describing exactly where they are 
becomes problematical.  200 meters south of the X Y junction on the north side 
of the highway.
When reporting I use JOSM to pick up the street name from OSM then cut and 
paste it into the Web form.  I invariably make mistakes when trying to type in 
names such as Bottriell Way.
So to make this work the municipality and the phone company etc. have to be 
able to recognise the OLC codes.  I probably need to add the boxes as a node 
into OSM initially just those that have Graffiti, some particular ones are more 
frequently covered than others. 
They may have to be transcribed, so do OLC codes incorporate a check digit?
Anyone have any experience with working with municipalities and phone companies 
etc in this way?  Yes Lat and Long would work but might be confusing to people 
who have to work with them, again check digits would avoid transcription errors.
I also need something to generate an OLC code when using JOSM.  I could use 
OSMand but its difficult to cut and paste from one device to another.
Inspiration anyone?
Thanks John___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

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

Re: [Talk-GB] un-named roads in UK

2018-08-29 Per discussione David Woolley


On 29/08/18 21:21, Jubal Harpster wrote:

Rosneath Castle Caravan Park



https://www.openstreetmap.org/way/92291906



_https://goo.gl/maps/5zn1EEXwYER2_



_https://binged.it/2BCrYOr_



OSM has the name on the actual caravan park, which sounds more likely: 
.


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

Re: [Talk-cz] maperská minirecenze MI 8

2018-08-29 Per discussione Jan Macura

Ahoj,

On Wed, 29 Aug 2018 at 09:30, majka  wrote:

> On Tue, 28 Aug 2018 at 23:37, Jan Macura  wrote:
>
>>
>> Zrychlení fixu by měl být logický důsledek většího množství viditelných
>> satelitů.
>>
>
> Ale tak nějak ne důsledek jediný...
>

Jestli věříš, že důsledkem bude i zpřesnění polohy, tak nečekej zázraky.
Mělo by se tím zlepšit to, že poloha bude méně často lítat o stovky metrů
do háje, protože přijímač má na výběr z většího množství satelitů, tím
pádem se nemusí spolíhat zrovna na ten, co je 10° nad obzorem, a taky
dokáže snáz vyloučit hrubý chyby jako multipath.
Absolutní určení polohy se tím ale o moc nezlepší. Nezlepší se tím totiž
ani chod hodin, ani se nezmenší vlivy troposféry a ionosféry na signál. A
tyhle 3 faktory jsou největší kazisvěti pro GNSS měření. Těch 30 cm, co
avizuje Xiaomi je medle čistě marketingový tah. V současnosti ani v
nejbližší budoucnosti se mobily ani ostatní běžné přijímače pod 1 m
přesnost nedostanou.

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

Re: [Talk-GB] GB does not include Northern Ireland

2018-08-29 Per discussione Martin Wynne




Even in these days of Brexit, I don't think there's any movement for
Northern Ireland to leave GB.  You've been misinformed!


Hi Toby,

Northern Ireland is part of the UK but it's not part of GB.

GB is England, Scotland and Wales.

The official title of this country is "The United Kingdom of Great 
Britain and Northern Ireland".


regards,

Martin.

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

Re: [Talk-cz] WeeklyOSM CZ 421

2018-08-29 Per discussione Jan Macura

On Tue, 28 Aug 2018 at 09:53, Tom Ka  wrote:

> pro JOSM:  tms[16]:https://osm.fit.vutbr.cz/strava/{zoom}/{x}/{y}.png
>
> do osmap.cz doplnim jak bude chvile a dam vedet. Dlazdice se zatim
> tahaji ale mensi zoomy uz funguji, takze je mozne vyzkouset.
>

Výborný, dík!
To je heatmapa všech aktivit? Jak moc náročné (asi hlavně na HW) by bylo
mít ty vrstvy odděleně pro běh/kolo/zimní sporty (jako to bylo funkční v
JOSM svého času)?

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

Re: [OSM-talk] Open Location Code and Graffiti

2018-08-29 Per discussione john whelan

But what is needed to make it work?

Thanks John

On Wed, 29 Aug 2018, 3:59 pm Pine W,  wrote:

> Thanks for sharing the idea of reporting problems like graffiti using
> coordinates. For some reason this idea never crossed my mind until I read
> your email. This would have been useful for me on one occasion in
> particular when I was trying to describe the location of graffiti in a
> public park. I can think of other types of situations where coordinates
> would be more useful than saying something like "200 feet north of the iron
> statue and on the west side of the gatehouse, above a path that goes to the
> creek".
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
>
>
> On Sat, Aug 25, 2018 at 10:06 PM john whelan 
> wrote:
>
>> It sounds an odd combination but locally you can report Graffiti to the
>> municipality and they arrange for it to be cleaned up by the phone company,
>> electric company etc.
>>
>> The targeted electric boxes are often at the back of houses or on
>> stretches of highway that have no houses which means describing exactly
>> where they are becomes problematical.  200 meters south of the X Y junction
>> on the north side of the highway.
>>
>> When reporting I use JOSM to pick up the street name from OSM then cut
>> and paste it into the Web form.  I invariably make mistakes when trying to
>> type in names such as Bottriell Way.
>>
>> So to make this work the municipality and the phone company etc. have to
>> be able to recognise the OLC codes.  I probably need to add the boxes as a
>> node into OSM initially just those that have Graffiti, some particular ones
>> are more frequently covered than others.
>>
>> They may have to be transcribed, so do OLC codes incorporate a check
>> digit?
>>
>> Anyone have any experience with working with municipalities and phone
>> companies etc in this way?  Yes Lat and Long would work but might be
>> confusing to people who have to work with them, again check digits would
>> avoid transcription errors.
>>
>> I also need something to generate an OLC code when using JOSM.  I could
>> use OSMand but its difficult to cut and paste from one device to another.
>>
>> Inspiration anyone?
>>
>> Thanks John
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-be] Opportuniteit voor OV mapper.

2018-08-29 Per discussione Marc Coevoet


Besten,

Vanaf 1 sept verandert het OV van Duinkerke.  Er zal niet alleen een bus 
zijn om de 10' in het centrum, het schema van de stadsbedekking 
verandert totaal.
En bovendien, de bus zal IEDERE dag GRATIS zijn. (al sinds een drietal 
jaar gratis in het weekend).


Een kans dus voor een mapper, om de ganse dkbus.com te herschrijven in 
dkbus2018.com



Marc
PS: en wat heeft dat nu met Belgie te maken?  Wel de bus start oa in 
Adinkerke, aan het station.  Ipv ieder uur nu zowat om de 15' tot aan 
een groot knooppunt in Leffrinckoucke.

--
The "Penguin" has arrived - and he's not going away - ever.
For former Apple users: Xubuntu.org (menu's up left)
For former Windows users: Lubuntu.org (menu's down left)

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

Re: [Talk-it] SENTIERO NON PERCORRIBILE

2018-08-29 Per discussione Martin Koppenhoefer



sent from a phone

> On 29. Aug 2018, at 19:21, liste DOT girarsi AT posteo DOT eu 
>  wrote:
> 
> onestamente seguo, ma non ci capisco nulla, perchè manca l'informazione 
> importante, di che ostacolo/impedimento si tratta?


si, infatti, per dare una risposta concreta dovremmo conoscere meglio la 
situazione (tipo di ostacolo, eventuale segnaletica, ecc.)

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

[Talk-GB] un-named roads in UK

2018-08-29 Per discussione Jubal Harpster

Hi Everyone,



Our Open Maps team (https://github.com/microsoft/open-maps) has been taking a 
closer look at OSM in the UK.  Some of you may have seen my session in Milan 
where we talked about Microsoft’s ongoing OSM work in Australia.



We found a few examples of roads missing names that we could use some local 
help with. There does not appear to be an official name for the examples below 
and we’re trying to figure out if they came from a local source, ground survey 
or something else entirely.


Road Name

OSM

Google

Bing

Coach road estate

https://www.openstreetmap.org/way/67494787

https://goo.gl/maps/PQXATz4iNMQ2

https://binged.it/2o1mF1v

Rosneath Castle Caravan Park

https://www.openstreetmap.org/way/92291906

https://goo.gl/maps/5zn1EEXwYER2

https://binged.it/2BCrYOr

Merville Garden Village

https://www.openstreetmap.org/way/139461452

https://goo.gl/maps/YdH5HCvhTqK2

https://binged.it/2BCq9Rx

Stadium Mews

https://www.openstreetmap.org/way/260127900

https://goo.gl/maps/JJNxamCgLy12

https://binged.it/2C0LAw1




These are not major roads but they are associated with a large number of 
residential addresses so any help understanding the source of the road names 
would be helpful.



Thank You

-Jubal

https://www.openstreetmap.org/user/jharpster

https://github.com/jharpster


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

Re: [Talk-GB] Road refs

2018-08-29 Per discussione Richard Fairhurst

Toby Speight wrote:
> That's why we have
> rendering rules - if you don't like the rendering, change the rules.

What you're suggesting would imply that every worldwide site using OSM data
to display a consumer-facing map, or provide routing, needs to write a
special exception for Great Britain. With the best will in the world, that
doesn't and isn't going to happen. (I think only one such site does so, and
it's the one I run!)

Dave's edit (minutiae about highway_authority_ref vs unsigned_ref vs
official_ref aside[1]) brings this country into line with how most of the
rest of the world does it: the ref= tag is for signposted references. See
how https://wiki.openstreetmap.org/wiki/Key:ref#Examples_on_ways refers to
"on the ground", "on the signs", "the usage on the signs".

Richard

[1] Personally, I honestly don't mind whether it's unsigned_ref or admin_ref
or official_ref or highway_authority_ref or one of the many other things
that have been suggested over the years. It might be worth having the
conversation here to see if there's something that people can coalesce
around, and then no doubt a further edit would be possible.

At that point, though, I would be tempted to bow out and redirect my
energies to the intriguing question of how an entirely bogus pub appears to
have survived in an allegedly well-mapped urban area for eight years. ;)
https://www.openstreetmap.org/node/678796800/history

--
Sent from: http://gis.19327.n8.nabble.com/Great-Britain-f5372682.html

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

Re: [OSM-talk] Open Location Code and Graffiti

2018-08-29 Per discussione Pine W

Thanks for sharing the idea of reporting problems like graffiti using
coordinates. For some reason this idea never crossed my mind until I read
your email. This would have been useful for me on one occasion in
particular when I was trying to describe the location of graffiti in a
public park. I can think of other types of situations where coordinates
would be more useful than saying something like "200 feet north of the iron
statue and on the west side of the gatehouse, above a path that goes to the
creek".

Pine
( https://meta.wikimedia.org/wiki/User:Pine )


On Sat, Aug 25, 2018 at 10:06 PM john whelan  wrote:

> It sounds an odd combination but locally you can report Graffiti to the
> municipality and they arrange for it to be cleaned up by the phone company,
> electric company etc.
>
> The targeted electric boxes are often at the back of houses or on
> stretches of highway that have no houses which means describing exactly
> where they are becomes problematical.  200 meters south of the X Y junction
> on the north side of the highway.
>
> When reporting I use JOSM to pick up the street name from OSM then cut and
> paste it into the Web form.  I invariably make mistakes when trying to type
> in names such as Bottriell Way.
>
> So to make this work the municipality and the phone company etc. have to
> be able to recognise the OLC codes.  I probably need to add the boxes as a
> node into OSM initially just those that have Graffiti, some particular ones
> are more frequently covered than others.
>
> They may have to be transcribed, so do OLC codes incorporate a check digit?
>
> Anyone have any experience with working with municipalities and phone
> companies etc in this way?  Yes Lat and Long would work but might be
> confusing to people who have to work with them, again check digits would
> avoid transcription errors.
>
> I also need something to generate an OLC code when using JOSM.  I could
> use OSMand but its difficult to cut and paste from one device to another.
>
> Inspiration anyone?
>
> Thanks John
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] Road refs

2018-08-29 Per discussione liste DOT girarsi AT posteo DOT eu

0> In article ,
0> Dave F. mailto:davefoxfa...@btinternet.com> ("Dave") wrote:

Dave> Point about OSM wiki: IMO giving multiple options for the same
Dave> entity leads to confusion & errors so should be avoided.

That's exactly what's problematic about "highways_authority_ref": it
creates a tag that contains the same information as belongs in "ref".

Based on the name, the similarity to ncn_ref and the like suggests a
non-authoritative alternative identifier.

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

Re: [Talk-it] aggiornamento emergency=access_point


Il 28/08/2018 20:04, demon.box ha scritto:

ciao, dunque, la query precisa è questa:

http://overpass-turbo.eu/s/BrH



Ciao demon, se vuoi ho estratto il tuo file e dopo un pò di ravanamenti 
ho aggiunto il nome LumeCodice al ref.


Se non hai già fatto te lo mando in formato *.geojson, basta caricarli 
in Josm, anche se ci sono tre ref mancanti, basta che li modifichi in 
seconda istanza, sono questi tre:


- https://www.openstreetmap.org/node/5615887302

- https://www.openstreetmap.org/node/5615887303

- https://www.openstreetmap.org/node/5615887330


--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [Talk-GB] GB does not include Northern Ireland

0> In article 
,
0> Dan S. mailto:danstowell%2b...@gmail.com> ("Dan") wrote:

Dan> The documentation happened after-the-fact rather than in advance,
Dan> as the AECoC demands.

There's still no documentation on the tag wiki at [1] or [2].
Interestingly, there is a mention of "unsigned_ref" [3] that's close to
what's proposed.  Perhaps that could be a way forward?

[1] https://wiki.openstreetmap.org/wiki/Key:ref >
[2] https://wiki.openstreetmap.org/wiki/Key:highway_authority_ref >
[3] https://wiki.openstreetmap.org/wiki/Key:unsigned_ref >

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

Re: [Talk-GB] Road refs

2018-08-29 Per discussione David Woolley


On 29/08/18 20:25, Toby Speight wrote:

Thanks for that - it predates my joining this list.  It seems to (partially)
answer only my first question - it's to benefit those who don't like their
rendering (on paper/screen or on a navigation device).  That's why we have
rendering rules - if you don't like the rendering, change the rules.  Using
the wrong tag for the data (especially a totally undocumented tag) to get a
rendering you like is really not helpful.



The people it benefits are people using OSM to navigate in vehicles, 
whether with routing software or with visual maps, as displaying 
information that doesn't exist on the ground results in their looking 
for signs that don't exist.


I would argue that the people tagging for the renderer are those who add 
references that don't exist on the ground and are not actually 
nationally unique.


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

Re: [Talk-GB] Road refs

2018-08-29 Per discussione Andy Townsend


On 29/08/2018 20:25, Toby Speight wrote:

Thanks for that - it predates my joining this list.  It seems to (partially)
answer only my first question - it's to benefit those who don't like their
rendering (on paper/screen or on a navigation device).  That's why we have
rendering rules - if you don't like the rendering, change the rules.  Using
the wrong tag for the data (especially a totally undocumented tag) to get a
rendering you like is really not helpful.


How would you suggest that data is tagged so that a renderer or a router 
knows the true local situation, e.g. "This reference tag, B1363, appears 
on signs is nationally unique and is something that drivers can use as a 
reference, but this other reference tag, C91, doesn't appear on signs, 
is unique only to the local authority that issued it, and can't be used 
for navigation"?  It's not as simple as saying "all B road refs and 
signed and all C road refs are unsigned" - there are quite a few exceptions.


Best Regards,

Andy


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

Re: [Talk-at] Quantität vor Qualität beim BEV-Adressimport?

2018-08-29 Per discussione various

Hallo, 

so, wie ich das sehe:
geocodec/.../adresshistory bevorzugt Nodes gegenüber Gebäudetagging. Mit seiner 
Arbeitsweise, die er selbst mehrfach erklärt hat, funktioniert das ganze 
einfach so, dass er zuerst alles setzt und danach alle Doppeltadressen löscht. 
Das zieht natürlich nach sich, dass er fröhlich die Gebäudeadressen, die vorher 
da waren, löscht. Ich behaupte inzwischen einfach, er macht das auch 
absichtlich so, weil es anders auch einfach mehr Aufwand wäre.
Was er ebenfalls macht ist, seine eigenen Fehler nicht auszubessern, auch nach 
Hinweisen nicht. Darum kümmert er sich vielleicht später mal, sagt er immer 
wieder oder er redet sich damit heraus, dass die Quelle halt nicht besser ist 
und macht nichts, in der Hoffnung, dass jemand anderes das behebt (was auch 
meist passiert).
Was zusätzlich ist, er ignoriert alles, was nicht Hausnummern betrifft, schön 
gesehen auch im Forum, wo er von mir mehrfach darauf hingewiesen wurde, dass er 
eine Adressnode gesetzt hat, ohne überhaupt einen Gebäudeumriss zu haben. Die 
Straße, klar auf Basemap erkenntlich hat er auch ignoriert und nicht 
hingezeichnet. Da ich mich dort auskannte, habe ich das dann nachgeholt. Auf 
meinen erneuten Hinweis, bevor ichs selbst gemacht habe, wurde nur pampig 
reagiert.

Seine gesamte Arbeitsweise fußt imho auf: 
Ich mach mal, bis jemand mir sagt, was ich falsch mache. Dann passe ich das an 
und mache weiter, bis der nächste auf einen Fehler draufkommt, dann passe ich 
das wieder an. Die vergangenen Sachen sind mir wurscht, die will ich nicht noch 
mal angreifen.

Einen kompletten Revert halte ich für unsinnig, trotz aller Fehler und 
persönlicher, äh, unstimmigkeiten, bringen die ganzen Adressen, die er einträgt 
einen großen Mehrwert, imho. 
Da noch eher genauere Kontrolle und Reverts der betroffenen Changesets und wenn 
er sich wieder mit so bescheuerten Argumenten dagegen wehrt, dass er selber mal 
seine Fehler ausbessert, einen 0-day Ban bis er sich mal dahinterklemmt und 
seine Fehler ausbessert. 
Die Fehler mach er eh ständig. 

Mit freundlichen grüßen

ps: Die inoffizielle Übereinkunft mit Hausnummern ist schön und gut, hilft aber 
nix, wenn man das nirgendwo nachlesen kann oder darauf hingewiesen wird. Im 
großen und ganzen ist es wurscht. 

> Robert Kaiser  hat am 28. August 2018 um 14:06 geschrieben:
> 
> 
> andreas wecer schrieb:
> > alleine in dem einen
> > Changeset wurden bei 200 Gebäuden die vorhandenen Adressen bei den Gebäuden
> > gelöscht und stattdessen ein Node gesetzt.
> 
> IMHO gehören Chagesets, die das machen, revertet. Wenn er dann weint, 
> weil das nur ein Teil des Changesets ist, dann soll er entweder mehr 
> überlegen, was er macht, oder auf kleinere Changesets aufteilen, damit 
> Kontroversen und Reverts nicht gleich viele gute Dinge auch betreffen.
> 
> Einerseits ist in Ö die inoffizielle Übereinkunft, dass Adressen auf das 
> Gebäude getaggt gehören, wenn eindeutig eine 1:1-Relation zwischen 
> Adresse und Gebäude herrscht. Andererseits ist es gegen die 
> OSM-Vorgehensweise, solche Dinge an bestehenden Objekten umzuändern, 
> ohne wirklichen Mehrwert für diese Objekte zu schaffen und auch ohne 
> vorher auf Listen/Foren-Diskussion eine breite Zustimmung zu dieser 
> Änderung bekommen zu haben.
> 
> Der Revert muss schon alleine deshalb sein, weil durch unreflektierte 
> Imports schon einmal die Community in Ö deutlich geschwächt wurde und 
> wir das nicht mehr zulassen können.
> 
> > Die Aussage, "Was dem amtlichen BEV genügt, sollte einstweilen auch für OSM
> > ausreichend sein", finde ich einigermaßen originell
> 
> Die Aussage ist schlichtweg BS. Wir wissen, dass jeder Datensatz Fehler 
> hat, aber mal abgesehen davon sind wir kein Amt, und nicht das BEV. Wir 
> haben andere Reglen und andere Zwecke. Wir haben keine bezahlten 
> Mitarbeiter, die wir schicken können, um Daten zu korrigieren, wenn "da 
> oben" wer beschließt, dass irgendwas jetzt sein muss. Wir haben eine 
> freiwillige Community, die es sehr vorsichtig zu hegen und pflegen gibt, 
> und wenn wir die vergraulen (weil wir z.B. ihre Daten mit einem Import 
> überschreiben), dann schadet das dem Projekt langfristig.
> 
> Daher: Einzeln recherchierte kleine Changesets (wie viele von den im 
> ländlichen Raum bestehenden Gebäuden und Adressen) übertrumpfen den 
> Import aus jedweglichen externen Datensätzen immer, schon alleine, weil 
> sie von einer breiteren and in Summe engagierteren Community kommen.
> 
> Robert Kaiser
> 
> 
> ___
> 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: [Talk-GB] GB does not include Northern Ireland

0> In article <6591308.YUxS5xHkjF@solus>,
0> WebMaster@Killyfole org uk mailto:webmas...@killyfole.org.uk> ("Wou") 
wrote:

Wou> ... GB doesn't include Northern Ireland, ...

Even in these days of Brexit, I don't think there's any movement for
Northern Ireland to leave GB.  You've been misinformed!

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

[Talk-pe] Nomad Maps entra en Peru!

2018-08-29 Per discussione alban vivert

Buenos dias a todos,


Me llamo Alban Vivert, soy un geografo/cartografo francés.


Les escribo para hablarles de un proyecto que estoy haciendo con el apoyo
de una ONG francesa (http://www.cartong.org/) que se llama *Nomad Maps*.


Se trata de  un recorrido de seis meses en bicicleta a través de tres
países andinos –Colombia, Ecuador y Perú– enfocado hacia “las posibilidades
que ofrece la cartografía y la información geográfica colaborativa como
herramienta de desarrollo”.


Después de 4000 kilometros recorridos desde mayo, Voy a entrar a Peru esta
semana por Jaen.

Mi proyecto tiene  4 objetivos :


 1 - Entrar en contacto con las comunidades locales OpenStreetMap, conocer
sus métodos y proyectos cartográficos, y comunicar en mi página web Nomad
Maps y en las redes sociales.
2 - Crear microproyectos de cartografía
colaborativa in situ o participar a unos ya existentes (1 o 2 semanas
max.). En el caso de que éstos sean más extensos, se propondría un apoyo de
CartONG y de su comunidad de voluntarios.
3 - Cartografiar in situ sobre
OpenStreetMap y Mapillary para enriquecer esas dos bases de datos
geográficos y contribuir así en la cartografía de las zonas visitadas.
4- Promover un modo de viaje original, limpio y sostenible con la bicicleta
y útil para las comunidades visitadas a través de la cartografía.

Ya tuve la oportunidad de conocer a *11 miembros* de Open Street Map
Colombia y Ecuador .
A finales del mes de septiembre, iré a presentar los resultados al *SOTM
Latam* que tendra lugar en Buenos Aires ( https://state.osmlatam.org/ )

Pueden mirar con mas detalles la pagina web del proyecto (
http://www.nomadmaps.net/  ), la parte "Le Projet" (= El proyecto) esta
traducida en castellano).

Mi recorrido en Peru no esta definido aun o sea que no duden en escribirme y
tal vez nos podemos conocer y encontrar para intercambiar sobre el
maravilloso entorno de Open Street Map!

Aqui unos enlaces:
Pagina  web:  http://www.nomadmaps.net/
Trailer: https://www.youtube.com/watch?v=20BgcfE_v30

Facebook :
https://www.facebook.com/NomadMapsProject/

mi correo : albanviv...@gmail.com

Gracias por su atencion, espero tener muchas respuestas suyas ;)

Hasta pronto,

Alban Vivert
___
Talk-pe mailing list
Talk-pe@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pe

Re: [Talk-GB] Road refs

0> In article <1535456684095-0.p...@n8.nabble.com>,
0> Richard Fairhurst mailto:rich...@systemed.net> ("Richard") wrote:

Richard> Toby Speight wrote:
>> Who is responsible for coordinating the related changes to software -
>> editors, renderers, converters and QA tools - that are required?  I
>> see no sign of any of this having started.

Richard> No changes are required to core OSM software, but if your own
Richard> niche requires a map on which C-road refs are displayed (and I
Richard> recognise you from the SABRE forums, so I guess that might be
Richard> the case ;) ) I'd be more than happy to help you and/or others
Richard> set up a server to do that. I'm sure there are other people
Richard> here who'd extend the same offer of help.

Interesting that you say there's a "niche" where road refs should be
displayed; I consider it a "niche" that wants them hidden.  I don't see
that we have to mis-tag them all to have them hidden - I can see it
would be useful to have a map with less clutter, but it shouldn't be
hard to do that without having to mangle the underlying OSM database!

Yes, I appreciate that if the highways_authority_ref were documented and
somehow agreed to be correct, then for mkgmap it would be a simple
matter of "add ref ${highways_authority_ref};" near the beginning; it
would be a bit harder to get a workable tag template for Merkaartor, but
tools like KeepRight and Geofabrik QA aren't so easily adjusted, and
unlikely to adopt new tagging until it's at least documented.

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

Re: [Talk-GB] Road refs

0> In article 
,
0> Andrew Hain mailto:andrewhain...@hotmail.co.uk> ("Andrew") wrote:

Andrew> Toby, I really think you need to read through the conversation
Andrew> archived at
Andrew> 
https://lists.openstreetmap.org/pipermail/talk-gb/2018-August/thread.html
Andrew> and answer the points discussed there.

Thanks for that - it predates my joining this list.  It seems to (partially)
answer only my first question - it's to benefit those who don't like their
rendering (on paper/screen or on a navigation device).  That's why we have
rendering rules - if you don't like the rendering, change the rules.  Using
the wrong tag for the data (especially a totally undocumented tag) to get a
rendering you like is really not helpful.

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

[Talk-it] Incontro gruppo Osm-Veneto di ottobre

2018-08-29 Per discussione Matteo Zaffonato

Ciao a tutti,
volevo segnalare ai mappatori veneti non iscritti alla ML Talk-it-Veneto
l'incontro del gruppo Osm-Veneto di ottobre a Padova.

https://lists.openstreetmap.org/pipermail/talk-it-veneto/2018-August/75.html

Ciao, grazie
Matteo "Zaffo80" Zaffonato
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Frazioni con civici ripetuti

2018-08-29 Per discussione Federico Cortese

On Wed, Aug 29, 2018 at 8:23 PM Martin Koppenhoefer
 wrote:
>
> si potrebbero mappare come entità "place", che non hanno requisiti del tipo 
> amministrativo politico. Per il perimetro si potrebbe prendere il confine del 
> centro abitato.
>

Era proprio ciò a cui mi riferivo, per quanto non sono certo che
risolva il problema; in caso positivo si tratterebbe di un rimedio
veloce, rispetto alla mappatura di addr:hamlet su tutti i numeri
civici.

Ciao,
Federico

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

Re: [Talk-it] Frazioni con civici ripetuti

2018-08-29 Per discussione Martin Koppenhoefer

2018-08-29 19:04 GMT+02:00 EneaSuper :

> Federico Cortese wrote
> > Attualmente abbiamo Cavasagra
> > (https://www.openstreetmap.org/node/1402465140) e Casacorba
> > (https://www.openstreetmap.org/node/1423423318) mappate come nodi, se
> > invece fossero mappate come poligoni sarebbe facile capire a quale
> > frazione appartengano le strade.
>
> Da quello che so (purtroppo) le frazioni sono enti che non hanno un
> territorio geopolitico come i comuni o le provincie, quindi mapparle per
> aree mi pare sbagliato, nonché impossibile da fare.




si potrebbero mappare come entità "place", che non hanno requisiti del tipo
amministrativo politico. Per il perimetro si potrebbe prendere il confine
del centro abitato.

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

Re: [Talk-at] Quantität vor Qualität beim BEV-Adressimport?

2018-08-29 Per discussione grubernd


On 2018-08-29 10:38, vari...@mailbox.org wrote:
Es ist alles recht sachlich hier. Er hat nicht zu Gewalt aufgerufen, 
weder direkt noch indirekt. Das war einfach ein sarkastisches "früher 
hätte man". Und was wir heute machen sollen/sollten, nun, das wird hier 
diskutiert.


Wenn du bei so einer Aussage probleme hast, solltest du an die Uni in 
den Safe-Space gehen, gibts sicher. Muss man ja bald alles auf die 
Waagschale legen, was man sagt oder schreibt.





danke. ich hätte das nicht so schön schreiben können. =)


grüsse,
grubernd

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

Re: [Talk-it] SENTIERO NON PERCORRIBILE

Riguardo alle tue considerazioni riguardo la renderizzazione:

anche se sono del tutto nuovo qui mi sembra di capire che uno dei dogmi 
principali di OSM sia che con i DATI che inseriamo, tendiamo a costruire un 
MODELLO del territorio il più vicino possibile alla realtà.

Sulla base di quel modello, poi, altre applicazioni potranno provvedere alla 
rappresentazione grafica dello stesso, ma COME questo venga fatto dalle varie 
applicazioni è un problema assolutamente trascurabile (ma ovviamente ci si 
augura che le applicazioni siano ragionevoli e diano una rappresentazione 
grafica consistente con la realtà modellata)

Personalmente ADORO questo concetto, che in informatica si definisce 
"Separation of Concerns", e lo sposo al 100%!

Quello che invece non mi è chiaro, leggendo il wiki, è se questi oggetti 
"obstacle" in qualche modo blocchino o meno la "routabilità" del percorso. 
Cioè, se metto un nodo "obstacle" in coincidenza con il nodo di una way, questa 
way viene esclusa dall'insieme delle possibili way per andare dal punto A al 
punto B? Ed in caso, per quale tipo di mezzi? Un obstacle potrebbe bloccare una 
bicicletta, ma non un pedone, per esempio...

On 2018-08-29 19:32, Sergio Manzi wrote:
> Per essere ultrapreciso penso che dovresti mettere 
> obstacle_description:it=Masso di tot metri. Blocca il sentiero, ma è 
> aggirabile a monte (per fare un esempio)
>
>
> On 2018-08-29 19:21, liste DOT girarsi AT posteo DOT eu wrote:
>> Il 29/08/2018 19:12, Sergio Manzi ha scritto:
>>> ... potrebbe anche essere obstacle=landslide (frana), già usato in 4 casi 
>>> (vedi [1])
>>>
>>> [1] https://taginfo.openstreetmap.org/keys/?key=obstacle#values
>>>
>>
>> onestamente seguo, ma non ci capisco nulla, perchè manca l'informazione 
>> importante, di che ostacolo/impedimento si tratta? se parliamo di dettaglio.
>>
>> Diversamente questo ho capito, si sta cercando il modo di ovviare ad un 
>> problema con un'altro problema, quello di renderizzare con qualcosa che non 
>> è necessariamente quello della realtà, ma che permette al navigatore di 
>> crware un routing diverso, giusto?  ;)
>>
>> Non si mappa per il rendering, e vabbè pazienza,ad una domanda non ho visto 
>> risposta, ovvero se si può passare lo stesso, però sinceramente qualche 
>> informazione e capire la situazione sarebbe più "onesto", utile per OSM non 
>> per i programmi e compagnia bella.
>>
>>
>

smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Nom des routes

2018-08-29 Per discussione Gwenaël Jouvin

… ce message me remémore un point que j’ai oublié dans mon message initial et 
mes excuses pour la digression à venir !

Ce type de nom peut actuellement se retrouver sur les « plaques de cocher » 
qu’il reste parfois aux détour de bâtiments, par exemple « Chemin de Grande 
communication nº0 de X à Y par Z ».
https://fr.wikipedia.org/wiki/Plaque_de_cocher

Bon, ça reste assez artificiel mais ces dénominations peuvent être très 
anciennes, héritées des routes impériales, etc.
Je comprendrais parfaitement que l’on considère ce genre d’info un peu trop 
historique pour entrer dans OSM, d’autant que sur les routes inter-urbaines, 
elle se retrouve peu sur le terrain (contrairement aux voies communales où les 
lieux-dits sont bien réels).

Pour l’anecdote historique, je serais intéressé par des éléments de source sur 
cette numérotation éventuellement due à Michelin. Je sais qu’ils en faisaient 
la pub lorsqu’ils ont lancé l’équipement des routes en signalisation en lave 
émaillée (commencée vers env. 1920 jusqu’à  env. 1970), mais la numérotation 
semble antérieure, comme en attestent les plaques de cocher bien plus anciennes 
que la signalisation Michelin. À moins que cette numérotation n’ait concerné 
que les voies locales, Vo et Ic à l’époque.


Le 29/08/2018 à 19:19, Christian Quest a écrit :
> "Route de X à Y" ?
> 
> Oui, on trouve ce genre de libellés sur le cadastre, mais ce ne sont de mon 
> point de vue que des éléments d'habillage et de contexte (un peu comme les 
> Nord/Sud Est/Ouest sur les lieux-dits).
> 
> Pour moi, ce n'est pas à mettre en name=*, car c'est au mieux une description 
> de l'itinéraire sur laquelle elle se trouve plus qu'autre chose, résidu des 
> noms des "voies de grande communication" avant qu'on ne procède à une 
> numérotation systématique de ces routes (initiée il me semble par Michelin 
> via une pétition).
> 
> Pour les "Route de X" c'est un peu différent car bien souvent ce sont des 
> noms vraiment utilisés sur le terrain, voire même des éléments d'adresses.
> 
> Bien sûr, comme toujours, on a de multiples zones grises et cas particuliers 
> où il est difficile de trancher de façon binaire !

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

Re: [OSM-talk-fr] date de l'imagerie

2018-08-29 Per discussione Brice Person


On 29/08/2018 18:59, Christian Quest wrote:

Je viens de regarder, ça me semble furieusement inexploitable.


Ça fait plusieurs années que j'exploite ce fichier en ce qui me concerne ;-)



1) on n'a que des boudingbox... donc des rectangles, alors que les 
dates de mises à jour suivent à peu près les limites de départements


Ça, ça dépend de ce que tu veux, les dates de BD ORTHO ou les dates de 
l'imagerie en production sur le géoportail. Mais je débarque donc je 
n'ai peut-être pas bien compris.


2) le minT / maxT qui indique la plage de date est systématiquement: 
maxT="2018-05-29" minT="2008-06-18"


Tu n'as pas du utiliser la version de l'autoconf avec la clé du 
géoportail. Cherche RGD 73-74 par exemple, les dates sont très largement 
variables d'une manière générale.




Ceci dit, tout n'est peut être pas à jeter... le maxT bien que global 
et unique est potentiellement utile et permettrai peut être de savoir 
de quand date le dernier changement "quelque part" sur la BDOrtho et 
donc le besoin de remettre à jour notre couche de datation ;)



Le mer. 29 août 2018 à 18:31, Brice Person > a écrit :


Bonjour,

Je découvre votre discussion sur le tard mais avez-vous pensé à
utiliser
l'autoconf du géoportail ?

Il y a les dates, les emprises (des bbox), et les min/max scale
denominator pour chaque sources.

Ça se présente comme ça :

https://wxs.ign.fr/choisirgeoportail/autoconf/?output=json

Par contre pour avoir l'exhaustivité des sources, bizarrement,
j'ai du
utiliser la clé d'api du geoportail (facilement trouvable dans la
console). Car il en manquait avec ma clé aussi (notamment RGD 73
74 près
de chez moi). Peut-être un bug.

Brice


On 28/08/2018 20:03, Frédéric Rodrigo wrote:
> Il s'agit de trouver dans quelle zone est une tuile pour
retourner une
> valeur. Le proxy du cadastre fait déjà :
> https://github.com/osm-fr/cadastre-joker/blob/master/whoots.rb#L23
>
>
> Le 28/08/2018 à 19:32, Vincent Privat a écrit :
>> Dans les metadata se serait effectivement mieux. Le format Bing
est
>> déjà géré par JOSM, ce serait donc le candidat idéal. Sinon on
a un
>> ticket pour gérer le format ESRI mais personne n'a encore
travaillé
>> dessus:
>> https://josm.openstreetmap.de/ticket/15604
>> Si on retient le format Bing, ça revient à rajouter le header
>> X-VE-TILEMETA-CaptureDatesRange
>> Pour la valeur du header on ne fait aucun contrôle dessus, le
format
>> est libre.
>> Vincent
>>
>> Le mar. 28 août 2018 à 17:16, Christian Quest
>> mailto:cqu...@openstreetmap.fr>
>>
a écrit :
>>
>>     Super boulot, ne reste plus qu'à trouver comment intégrer
ça dans le
>>     proxy et faire en sorte que JOSM puisse afficher l'info...
>>
>>     Je vois deux options:
>>
>>     - un rendu transparent qui indique la date des tuiles
d'ortho au
>> meme
>>     x/y/z... simple à mettre en oeuvre,
>>
>>     - un bout de script python qui injecte dans les entêtes l'info
>>     entre le
>>     proxy et le géoportail, et faire en sorte que JOSM puisse
l'afficher
>>     comme pour Bing (sûrement plus complexe)
>>
>>     Autre suggestion ?
>>
>>
>>     Le 24/08/2018 à 21:56, deuzeffe a écrit :
>>     > Un premier bilan donne :
>>     >
>>     > - 5 m : https://lite.framacalc.org/bd-ortho-millesime-par-dep
>>     > - 50 cm :
>> https://lite.framacalc.org/bd-ortho-millesime-par-dep-50cm
>>     > - 20 cm :
>> https://lite.framacalc.org/bd-ortho-millesime-par-dep-20cm
>>     >
>>     > À voir comment est-ce exploitable...
>>     > --
>>     > deuzeffe, qui aimerait bien que Christian revienne de
vacances et
>>     > donne son avis.
>>     >
>>     > On 17/08/2018 12:36, Christian Quest wrote:
>>     >> La source de l'umap ce sont les shapefile de mosaique de la
>>     BDORtho
>>     >> 5m... republiés dans OpenEventDatabase
>>     >>
>>     >> Par contre, il faut aussi prévoir la mise à jour de cette
>>     source, car
>>     >> là ça commence à dater. Ce n'est pas parfait non plus
car c'est
>>     la BD
>>     >> Ortho 5m (donc gros pixels) alors qu'on a maintenant des
zones
>>     avec
>>     >> du 5cm (Paris).
>>     >>
>>     >> Sinon, l'IGN publie les années de prises de vues de la
BD Ortho
>>     >> département par département, ce qui peut être largement
suffisant
>>     >> comme info: http://professionnels.ign.fr/mises-a-jour
>>     >>
>>     >> Pour 2017 on trouve:
>>     >>
>>     >> 21-24-25-39-47-87-971-972-978 à 20cm
>>     >>
>>     >> 21-24-25-39-75-92-93-971-972-978 06-07-21-47 56
>>     13-25-39-47-87-971 à
>>

Re: [Talk-it] SENTIERO NON PERCORRIBILE

2018-08-29 Per discussione liste DOT girarsi AT posteo DOT eu

Per essere ultrapreciso penso che dovresti mettere 
obstacle_description:it=Masso di tot metri. Blocca il sentiero, ma è aggirabile 
a monte (per fare un esempio)


On 2018-08-29 19:21, liste DOT girarsi AT posteo DOT eu wrote:
> Il 29/08/2018 19:12, Sergio Manzi ha scritto:
>> ... potrebbe anche essere obstacle=landslide (frana), già usato in 4 casi 
>> (vedi [1])
>>
>> [1] https://taginfo.openstreetmap.org/keys/?key=obstacle#values
>>
>
>
> onestamente seguo, ma non ci capisco nulla, perchè manca l'informazione 
> importante, di che ostacolo/impedimento si tratta? se parliamo di dettaglio.
>
> Diversamente questo ho capito, si sta cercando il modo di ovviare ad un 
> problema con un'altro problema, quello di renderizzare con qualcosa che non è 
> necessariamente quello della realtà, ma che permette al navigatore di crware 
> un routing diverso, giusto?  ;)
>
> Non si mappa per il rendering, e vabbè pazienza,ad una domanda non ho visto 
> risposta, ovvero se si può passare lo stesso, però sinceramente qualche 
> informazione e capire la situazione sarebbe più "onesto", utile per OSM non 
> per i programmi e compagnia bella.
>
>




smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] SENTIERO NON PERCORRIBILE


Il 29/08/2018 19:12, Sergio Manzi ha scritto:

... potrebbe anche essere obstacle=landslide (frana), già usato in 4 casi (vedi 
[1])

[1] https://taginfo.openstreetmap.org/keys/?key=obstacle#values




onestamente seguo, ma non ci capisco nulla, perchè manca l'informazione 
importante, di che ostacolo/impedimento si tratta? se parliamo di dettaglio.


Diversamente questo ho capito, si sta cercando il modo di ovviare ad un 
problema con un'altro problema, quello di renderizzare con qualcosa che 
non è necessariamente quello della realtà, ma che permette al navigatore 
di crware un routing diverso, giusto?  ;)


Non si mappa per il rendering, e vabbè pazienza,ad una domanda non ho 
visto risposta, ovvero se si può passare lo stesso, però sinceramente 
qualche informazione e capire la situazione sarebbe più "onesto", utile 
per OSM non per i programmi e compagnia bella.



--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [OSM-talk-fr] Nom des routes

2018-08-29 Per discussione Christian Quest

"Route de X à Y" ?

Oui, on trouve ce genre de libellés sur le cadastre, mais ce ne sont de mon
point de vue que des éléments d'habillage et de contexte (un peu comme les
Nord/Sud Est/Ouest sur les lieux-dits).

Pour moi, ce n'est pas à mettre en name=*, car c'est au mieux une
description de l'itinéraire sur laquelle elle se trouve plus qu'autre
chose, résidu des noms des "voies de grande communication" avant qu'on ne
procède à une numérotation systématique de ces routes (initiée il me semble
par Michelin via une pétition).

Pour les "Route de X" c'est un peu différent car bien souvent ce sont des
noms vraiment utilisés sur le terrain, voire même des éléments d'adresses.

Bien sûr, comme toujours, on a de multiples zones grises et cas
particuliers où il est difficile de trancher de façon binaire !


Le mer. 29 août 2018 à 19:05, Gwenaël Jouvin  a
écrit :

> Bonsoir à toutes & tous,
>
> Parallèlement à la discussion sur les lieux-dits [1], je pense qu’il y a
> une carte à jouer sur le nommage des voies de communication —
> principalement /hors agglomération/, en ville les routes étant connues sous
> le terme de « rue ».
>
> Si les routes ont généralement une nomenclature sous la clef ref=, elles
> ont aussi un nom que l’on peut renseigner dans name=.
> Plusieurs cas se présentent :
> — la route a été nommée par la municipalité et ce qualificatif entre
> logiquement dans "name"="Route de …" ;
> — la route n’a pas de nom spécifique mais est nommée « administrativement
> » par ses embranchements, information trouvable dans le cadastre :
> "name"="Route départementale nº512 de Saint-Laurent à Sainte-Marie".
> Si elle bénéficie de deux noms, je pense que l’info du cadastre, bien que
> moins pertinente, peut tout de même être rangée dans alt_name.
>
> Cependant, cette dernière information peut poser problème lorsque la route
> est une ancienne nationale déclassée. Effectivement, les départements ont
> successivement repris la gestion d’anciennes nationales (au moins en 1972
> et en 2006) [2] et la nomenclature a parfois complètement changé,
> anéantissant les possibilités d’orientation par numéro pourtant si logique.
> De fait, le nom « Route de X à Y », inter-départemental voire
> inter-régional ; ne colle plus au numéro qui est devenu intra-départemental.
> On trouve d’ailleurs dans le cadastre des départementales actuelles
> toujours nommées « Route nationale… », donc, méfiance.
>
>
> Finalement, les noms des voies ont plutôt un intérêt au niveau local et on
> rejoint là le sujet des lieux-dits.
> Les voies communales et les chemins ruraux [3], si on ne voit pas
> systématiquement leur nomenclature sur le terrain, sont numérotés et nommés
> dans le cadastre (parfois, l’info est coupée dans le rendu, il faut aller
> sur le site internet officiel).
> Le nom de la voie donne parfois une autre orthographe des lieux-dits, ce
> qui peut permettre de trancher.
>
> Je me pose tout de même une question pratique : ces noms sont parfois
> longs, par exemple « Voie communale numéro 5 dite du Lieudit de Bas au
> Lieudit de Haut ».
> Étant donné que le numéro sera enregistré comme "ref"="C 5", il est
> possible de rendre le nom plus lisible, sous la forme « Voie communale du
> Lieudit de Bas au Lieudit de Haut ». Ça s’intègre mieux à la carte, on
> évite une redondance d’information sans trop dénaturer la source et
> l’expression est plus lisible pour l’utilisateur.
>
> Comme pour leurs grandes sœurs, on privilégiera le nom officiel s’il
> existe dans name= et le nom « cadastral » dans alt_name (ou autre clef ?).
>
>
> Étant néophyte, j’aimerais connaître vos pratiques sur le sujet.
>
> Merci.
>
>
> P.S. : certaines routes forment parfois frontière entre deux communes et,
> histoire de simplifier les choses, portent des nomenclatures et des noms
> propres à chacune d’entre-elles.
> Je pense que dans ce cas, nous ne pouvons guère que se reposer sur
> ref:[right|left] et name:[right|left], exemple :
> https://www.openstreetmap.org/way/83277707
>
>
> [1]
> https://lists.openstreetmap.org/pipermail/talk-fr/2018-August/089765.html
> [2]
> http://routes.wikia.com/wiki/Route_nationale_fran%C3%A7aise#Liste_historique_des_routes_nationales_fran.C3.A7aises
> [3]
> https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI06582168=LEGITEXT06071367
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [Talk-it] SENTIERO NON PERCORRIBILE

... potrebbe anche essere obstacle=landslide (frana), già usato in 4 casi (vedi 
[1])

[1] https://taginfo.openstreetmap.org/keys/?key=obstacle#values


On 2018-08-29 19:02, Sergio Manzi wrote:
>
> Secondo il wiki [1] "barrier" è un elemento artificiale (costruito 
> appositamente per limitare i movimenti) mentre "obstacle" è un elemento che 
> oggettivamente limita il passaggio e può essere di origine naturale.
>
> Quindi... direi "obstacle", ma come valore della chiave... non è prevista 
> quella giusta! Io *inventerei* "boulder" (vedi [2]), ma se non si vuole 
> essere troppo creativi, la cosa che gli si avvicina di più mi sembra essere 
> "heap", oppure anche solo "yes".
>
> Inoltre penso non farebbe male aggiungere anche una key "access" con valore 
> "no" se l'ostruzione blocca del tutto la possibilità di usufruire del 
> sentiero.
>
>
> P.S., Ciao a tutti, è il mio primo post sulla mailing-list: sono Sergio, da 
> Venezia...
>
>
> [1] 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle#Differences_with_other_keys
> [2] http://www.wordreference.com/enit/boulder
>
>
> On 2018-08-29 18:43, Roberto Brazzelli wrote:
>> Ok come proposta cosa vuol dire, si può usare?
>> Se utilizzo il tags barrier=block il render di openstretmap
>> non si modifica giusto...ma per quanto riguarda OSMand?
>>
>> Grazie mille
>>
>> Il 29/08/2018 16:44, Martin Koppenhoefer ha scritto:
>>>
>>>
>>> sent from a phone
>>>
>>> On 29. Aug 2018, at 12:13, Roberto Brazzelli >> > wrote:
>>>
 si presente con una grosso ostruzione nel mezzo?
>>>
>>>
>>> ci sono vari tags, forse barrier=block ? C’è anche obstacle come proposta:
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle
>>>
>>> e forse anche hazard, se ci fossero pericoli:
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard
>>>
>>> Ciao, Martin 
>>>
>>>
>>> ___
>>> 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
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Frazioni con civici ripetuti

2018-08-29 Per discussione EneaSuper

Federico Cortese wrote
> Attualmente abbiamo Cavasagra
> (https://www.openstreetmap.org/node/1402465140) e Casacorba
> (https://www.openstreetmap.org/node/1423423318) mappate come nodi, se
> invece fossero mappate come poligoni sarebbe facile capire a quale
> frazione appartengano le strade.

Da quello che so (purtroppo) le frazioni sono enti che non hanno un
territorio geopolitico come i comuni o le provincie, quindi mapparle per
aree mi pare sbagliato, nonché impossibile da fare.

Meglio proseguire il lavoro taggando singolarmente strade e civici.




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

[OSM-talk-fr] Nom des routes

2018-08-29 Per discussione Gwenaël Jouvin

Bonsoir à toutes & tous,

Parallèlement à la discussion sur les lieux-dits [1], je pense qu’il y a une
carte à jouer sur le nommage des voies de communication — principalement /hors
agglomération/, en ville les routes étant connues sous le terme de « rue ».

Si les routes ont généralement une nomenclature sous la clef ref=, elles ont
aussi un nom que l’on peut renseigner dans name=.
Plusieurs cas se présentent :
— la route a été nommée par la municipalité et ce qualificatif entre
logiquement dans "name"="Route de …" ;
— la route n’a pas de nom spécifique mais est nommée « administrativement » par
ses embranchements, information trouvable dans le cadastre : "name"="Route
départementale nº512 de Saint-Laurent à Sainte-Marie".
Si elle bénéficie de deux noms, je pense que l’info du cadastre, bien que moins
pertinente, peut tout de même être rangée dans alt_name.

Cependant, cette dernière information peut poser problème lorsque la route est
une ancienne nationale déclassée. Effectivement, les départements ont
successivement repris la gestion d’anciennes nationales (au moins en 1972 et en
2006) [2] et la nomenclature a parfois complètement changé, anéantissant les
possibilités d’orientation par numéro pourtant si logique. De fait, le nom «
Route de X à Y », inter-départemental voire inter-régional ; ne colle plus au
numéro qui est devenu intra-départemental.
On trouve d’ailleurs dans le cadastre des départementales actuelles toujours
nommées « Route nationale… », donc, méfiance.

Finalement, les noms des voies ont plutôt un intérêt au niveau local et on
rejoint là le sujet des lieux-dits.
Les voies communales et les chemins ruraux [3], si on ne voit pas
systématiquement leur nomenclature sur le terrain, sont numérotés et nommés
dans le cadastre (parfois, l’info est coupée dans le rendu, il faut aller sur
le site internet officiel).
Le nom de la voie donne parfois une autre orthographe des lieux-dits, ce qui
peut permettre de trancher.

Je me pose tout de même une question pratique : ces noms sont parfois longs,
par exemple « Voie communale numéro 5 dite du Lieudit de Bas au Lieudit de Haut
».
Étant donné que le numéro sera enregistré comme "ref"="C 5", il est possible de
rendre le nom plus lisible, sous la forme « Voie communale du Lieudit de Bas au
Lieudit de Haut ». Ça s’intègre mieux à la carte, on évite une redondance
d’information sans trop dénaturer la source et l’expression est plus lisible
pour l’utilisateur.

Comme pour leurs grandes sœurs, on privilégiera le nom officiel s’il existe
dans name= et le nom « cadastral » dans alt_name (ou autre clef ?).

Étant néophyte, j’aimerais connaître vos pratiques sur le sujet.

Merci.

P.S. : certaines routes forment parfois frontière entre deux communes et,
histoire de simplifier les choses, portent des nomenclatures et des noms
propres à chacune d’entre-elles.
Je pense que dans ce cas, nous ne pouvons guère que se reposer sur
ref:[right|left] et name:[right|left], exemple :
https://www.openstreetmap.org/way/83277707

[1] https://lists.openstreetmap.org/pipermail/talk-fr/2018-August/089765.html
[2]
http://routes.wikia.com/wiki/Route_nationale_fran%C3%A7aise#Liste_historique_des_routes_nationales_fran.C3.A7aises
[3]
https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI06582168=LEGITEXT06071367

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

Re: [Talk-it] SENTIERO NON PERCORRIBILE

Secondo il wiki [1] "barrier" è un elemento artificiale (costruito 
appositamente per limitare i movimenti) mentre "obstacle" è un elemento che 
oggettivamente limita il passaggio e può essere di origine naturale.

Quindi... direi "obstacle", ma come valore della chiave... non è prevista 
quella giusta! Io *inventerei* "boulder" (vedi [2]), ma se non si vuole essere 
troppo creativi, la cosa che gli si avvicina di più mi sembra essere "heap", 
oppure anche solo "yes".

Inoltre penso non farebbe male aggiungere anche una key "access" con valore 
"no" se l'ostruzione blocca del tutto la possibilità di usufruire del sentiero.

P.S., Ciao a tutti, è il mio primo post sulla mailing-list: sono Sergio, da 
Venezia...

[1] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle#Differences_with_other_keys
[2] http://www.wordreference.com/enit/boulder

On 2018-08-29 18:43, Roberto Brazzelli wrote:
> Ok come proposta cosa vuol dire, si può usare?
> Se utilizzo il tags barrier=block il render di openstretmap
> non si modifica giusto...ma per quanto riguarda OSMand?
>
> Grazie mille
>
> Il 29/08/2018 16:44, Martin Koppenhoefer ha scritto:
>>
>>
>> sent from a phone
>>
>> On 29. Aug 2018, at 12:13, Roberto Brazzelli > > wrote:
>>
>>> si presente con una grosso ostruzione nel mezzo?
>>
>>
>> ci sono vari tags, forse barrier=block ? C’è anche obstacle come proposta:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle
>>
>> e forse anche hazard, se ci fossero pericoli:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard
>>
>> Ciao, Martin 
>>
>>
>> ___
>> 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

smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] date de l'imagerie

2018-08-29 Per discussione Christian Quest

Je viens de regarder, ça me semble furieusement inexploitable.

1) on n'a que des boudingbox... donc des rectangles, alors que les dates de
mises à jour suivent à peu près les limites de départements
2) le minT / maxT qui indique la plage de date est systématiquement:
maxT="2018-05-29" minT="2008-06-18"

Ceci dit, tout n'est peut être pas à jeter... le maxT bien que global et
unique est potentiellement utile et permettrai peut être de savoir de quand
date le dernier changement "quelque part" sur la BDOrtho et donc le besoin
de remettre à jour notre couche de datation ;)


Le mer. 29 août 2018 à 18:31, Brice Person  a écrit :

> Bonjour,
>
> Je découvre votre discussion sur le tard mais avez-vous pensé à utiliser
> l'autoconf du géoportail ?
>
> Il y a les dates, les emprises (des bbox), et les min/max scale
> denominator pour chaque sources.
>
> Ça se présente comme ça :
>
> https://wxs.ign.fr/choisirgeoportail/autoconf/?output=json
>
> Par contre pour avoir l'exhaustivité des sources, bizarrement, j'ai du
> utiliser la clé d'api du geoportail (facilement trouvable dans la
> console). Car il en manquait avec ma clé aussi (notamment RGD 73 74 près
> de chez moi). Peut-être un bug.
>
> Brice
>
>
> On 28/08/2018 20:03, Frédéric Rodrigo wrote:
> > Il s'agit de trouver dans quelle zone est une tuile pour retourner une
> > valeur. Le proxy du cadastre fait déjà :
> > https://github.com/osm-fr/cadastre-joker/blob/master/whoots.rb#L23
> >
> >
> > Le 28/08/2018 à 19:32, Vincent Privat a écrit :
> >> Dans les metadata se serait effectivement mieux. Le format Bing est
> >> déjà géré par JOSM, ce serait donc le candidat idéal. Sinon on a un
> >> ticket pour gérer le format ESRI mais personne n'a encore travaillé
> >> dessus:
> >> https://josm.openstreetmap.de/ticket/15604
> >> Si on retient le format Bing, ça revient à rajouter le header
> >> X-VE-TILEMETA-CaptureDatesRange
> >> Pour la valeur du header on ne fait aucun contrôle dessus, le format
> >> est libre.
> >> Vincent
> >>
> >> Le mar. 28 août 2018 à 17:16, Christian Quest
> >> mailto:cqu...@openstreetmap.fr>> a écrit :
> >>
> >> Super boulot, ne reste plus qu'à trouver comment intégrer ça dans le
> >> proxy et faire en sorte que JOSM puisse afficher l'info...
> >>
> >> Je vois deux options:
> >>
> >> - un rendu transparent qui indique la date des tuiles d'ortho au
> >> meme
> >> x/y/z... simple à mettre en oeuvre,
> >>
> >> - un bout de script python qui injecte dans les entêtes l'info
> >> entre le
> >> proxy et le géoportail, et faire en sorte que JOSM puisse l'afficher
> >> comme pour Bing (sûrement plus complexe)
> >>
> >> Autre suggestion ?
> >>
> >>
> >> Le 24/08/2018 à 21:56, deuzeffe a écrit :
> >> > Un premier bilan donne :
> >> >
> >> > - 5 m : https://lite.framacalc.org/bd-ortho-millesime-par-dep
> >> > - 50 cm :
> >> https://lite.framacalc.org/bd-ortho-millesime-par-dep-50cm
> >> > - 20 cm :
> >> https://lite.framacalc.org/bd-ortho-millesime-par-dep-20cm
> >> >
> >> > À voir comment est-ce exploitable...
> >> > --
> >> > deuzeffe, qui aimerait bien que Christian revienne de vacances et
> >> > donne son avis.
> >> >
> >> > On 17/08/2018 12:36, Christian Quest wrote:
> >> >> La source de l'umap ce sont les shapefile de mosaique de la
> >> BDORtho
> >> >> 5m... republiés dans OpenEventDatabase
> >> >>
> >> >> Par contre, il faut aussi prévoir la mise à jour de cette
> >> source, car
> >> >> là ça commence à dater. Ce n'est pas parfait non plus car c'est
> >> la BD
> >> >> Ortho 5m (donc gros pixels) alors qu'on a maintenant des zones
> >> avec
> >> >> du 5cm (Paris).
> >> >>
> >> >> Sinon, l'IGN publie les années de prises de vues de la BD Ortho
> >> >> département par département, ce qui peut être largement suffisant
> >> >> comme info: http://professionnels.ign.fr/mises-a-jour
> >> >>
> >> >> Pour 2017 on trouve:
> >> >>
> >> >> 21-24-25-39-47-87-971-972-978 à 20cm
> >> >>
> >> >> 21-24-25-39-75-92-93-971-972-978 06-07-21-47 56
> >> 13-25-39-47-87-971 à
> >> >> 50cm
> >> >>
> >> >> Malheureusement, ces tableaux ne sont pas très simple à lire
> >> car on a
> >> >> des millésimes différent en fonction des niveaux de zoom.
> >> >>
> >> >> Si un courageux veut remettre ça au propre dans un beau CSV ça
> >> serait
> >> >> fort utile.
> >> >>
> >> >>
> >> >> Le 15/08/2018 à 02:26, marc marc a écrit :
> >> >>> Le 15. 08. 18 à 02:16, Jérôme Seigneuret a écrit :
> >>  la date de la prise de vu comme on peut l'avoir sur Google
> >> Earth ou
> >> >>> il y a les 2 lorsque les 2 sont disponibles.
> >> >>> la date de capture dans josm s'affiche chez moi avec
> >> >>> comme mention "métadonnée capture date"
> >> >>> et est visible par exemple avec la couche Bing
> >> >>> oui je sais c'est triste comme

Re: [Talk-it] SENTIERO NON PERCORRIBILE

2018-08-29 Per discussione Roberto Brazzelli


Ok come proposta cosa vuol dire, si può usare?
Se utilizzo il tags barrier=block il render di openstretmap
non si modifica giusto...ma per quanto riguarda OSMand?

Grazie mille

Il 29/08/2018 16:44, Martin Koppenhoefer ha scritto:



sent from a phone

On 29. Aug 2018, at 12:13, Roberto Brazzelli > wrote:



si presente con una grosso ostruzione nel mezzo?



ci sono vari tags, forse barrier=block ? C’è anche obstacle come proposta:
https://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle

e forse anche hazard, se ci fossero pericoli:
https://wiki.openstreetmap.org/wiki/Proposed_features/hazard

Ciao, Martin


___
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] date de l'imagerie

2018-08-29 Per discussione Brice Person


Bonjour,

Je découvre votre discussion sur le tard mais avez-vous pensé à utiliser 
l'autoconf du géoportail ?


Il y a les dates, les emprises (des bbox), et les min/max scale 
denominator pour chaque sources.


Ça se présente comme ça :

https://wxs.ign.fr/choisirgeoportail/autoconf/?output=json

Par contre pour avoir l'exhaustivité des sources, bizarrement, j'ai du 
utiliser la clé d'api du geoportail (facilement trouvable dans la 
console). Car il en manquait avec ma clé aussi (notamment RGD 73 74 près 
de chez moi). Peut-être un bug.


Brice


On 28/08/2018 20:03, Frédéric Rodrigo wrote:
Il s'agit de trouver dans quelle zone est une tuile pour retourner une 
valeur. Le proxy du cadastre fait déjà :

https://github.com/osm-fr/cadastre-joker/blob/master/whoots.rb#L23


Le 28/08/2018 à 19:32, Vincent Privat a écrit :
Dans les metadata se serait effectivement mieux. Le format Bing est 
déjà géré par JOSM, ce serait donc le candidat idéal. Sinon on a un 
ticket pour gérer le format ESRI mais personne n'a encore travaillé 
dessus:

https://josm.openstreetmap.de/ticket/15604
Si on retient le format Bing, ça revient à rajouter le header 
X-VE-TILEMETA-CaptureDatesRange
Pour la valeur du header on ne fait aucun contrôle dessus, le format 
est libre.

Vincent

Le mar. 28 août 2018 à 17:16, Christian Quest 
mailto:cqu...@openstreetmap.fr>> a écrit :


    Super boulot, ne reste plus qu'à trouver comment intégrer ça dans le
    proxy et faire en sorte que JOSM puisse afficher l'info...

    Je vois deux options:

    - un rendu transparent qui indique la date des tuiles d'ortho au 
meme

    x/y/z... simple à mettre en oeuvre,

    - un bout de script python qui injecte dans les entêtes l'info
    entre le
    proxy et le géoportail, et faire en sorte que JOSM puisse l'afficher
    comme pour Bing (sûrement plus complexe)

    Autre suggestion ?


    Le 24/08/2018 à 21:56, deuzeffe a écrit :
    > Un premier bilan donne :
    >
    > - 5 m : https://lite.framacalc.org/bd-ortho-millesime-par-dep
    > - 50 cm : 
https://lite.framacalc.org/bd-ortho-millesime-par-dep-50cm
    > - 20 cm : 
https://lite.framacalc.org/bd-ortho-millesime-par-dep-20cm

    >
    > À voir comment est-ce exploitable...
    > --
    > deuzeffe, qui aimerait bien que Christian revienne de vacances et
    > donne son avis.
    >
    > On 17/08/2018 12:36, Christian Quest wrote:
    >> La source de l'umap ce sont les shapefile de mosaique de la
    BDORtho
    >> 5m... republiés dans OpenEventDatabase
    >>
    >> Par contre, il faut aussi prévoir la mise à jour de cette
    source, car
    >> là ça commence à dater. Ce n'est pas parfait non plus car c'est
    la BD
    >> Ortho 5m (donc gros pixels) alors qu'on a maintenant des zones
    avec
    >> du 5cm (Paris).
    >>
    >> Sinon, l'IGN publie les années de prises de vues de la BD Ortho
    >> département par département, ce qui peut être largement suffisant
    >> comme info: http://professionnels.ign.fr/mises-a-jour
    >>
    >> Pour 2017 on trouve:
    >>
    >> 21-24-25-39-47-87-971-972-978 à 20cm
    >>
    >> 21-24-25-39-75-92-93-971-972-978 06-07-21-47 56
    13-25-39-47-87-971 à
    >> 50cm
    >>
    >> Malheureusement, ces tableaux ne sont pas très simple à lire
    car on a
    >> des millésimes différent en fonction des niveaux de zoom.
    >>
    >> Si un courageux veut remettre ça au propre dans un beau CSV ça
    serait
    >> fort utile.
    >>
    >>
    >> Le 15/08/2018 à 02:26, marc marc a écrit :
    >>> Le 15. 08. 18 à 02:16, Jérôme Seigneuret a écrit :
     la date de la prise de vu comme on peut l'avoir sur Google
    Earth ou
    >>> il y a les 2 lorsque les 2 sont disponibles.
    >>> la date de capture dans josm s'affiche chez moi avec
    >>> comme mention "métadonnée capture date"
    >>> et est visible par exemple avec la couche Bing
    >>> oui je sais c'est triste comme exemple :)
    >>>
    >>> Mais si quelqu'un est motivée pour coder l'injection des infos
    >>> dans les headers du proxy BDOrtho osm-fr, c'est techniquement
    possible
    >>> et un coup de main n'est jamais refusé :)
    >>> sinon c'est sur ma longue liste de chose à faire... et pas la
    moindre
    >>> idée de ce que cela va impliquer en boulot (j'ai pas encore
    regardé
    >>> la source de l'umap de Christian)
    >>> ___
    >>> 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

    --     Christian Quest - OpenStreetMap France


    ___
    Talk-fr mailing list
    Talk-fr@openstreetmap.org

Re: [Talk-GB] Some leisure=track not rendering