Re: [OSM-talk-fr] Tag pour les services d'un établissement, quand ils sont adaptés aux fauteuils roulants

[Yves P.]

> Le problème c'est qu'il s'agit de marques.
> 
> Les Tiralo ont aussi des Hippocampe 
> 
>  concurrents.

Je ne suis pas choqué (et d'ailleurs ce n'est pas directement en rapport avec 
la question de Violaine).
Pour moi c'est comme parler de frigidaire.
De plus c'est factuel : la plage xxx à des Hipocampes, la  à une autre 
système (dont j'ai oublié le nom).
> Pour le fait d'avoir une personne accompagnante, ça ne me semble pas dépendre 
> d'OSM : si c'est dans une structure, ça doit être bon et si c'est un fauteuil 
> à disposition dans un poste de surveillance c'est sans sûrement self 
> demerdum. Donc info non pertinente dans OSM ?
> 
Je ne te suis pas. Ce qui est pertinent, c'est ce qui est utile à une personne 
handicapé.
La question ici est dans quel tag mettre cette info importante.
> Quand je vois le guide de l'agglo de Lorient 
> 
>  ça me laisse perplexe :
> 
> Mais de tels fauteuils sur une plage non indiquée comme accessible... Le 
> second doit impliquer le premier.
> 
Logiquement oui. Après le handicap c'est beaucoup de système D
> Je sais que handimap.org trouvait que OSM manquait de tags. Voir leur FAQ 
> .
> 
La page a du évoluer ? Il n'est pas fait mention d'OSM mais de Google Maps et 
Google Earth ;)
> La contribution se fait via des associations (spécialistes) uniquement.
> 
Ou par des questionnaires mis en place par des associations spécialisées. Cf. 
Comment contribuer ? sur le site de Jaccede.
> Sans doute parce qu'un valide a du mal à entrer le niveau de richesse de 
> l'information requise
> 
Oui, et qu'il y a une "richesse" d'handicap, que chaque personne est 
différente, que les fauteuils ne se valent pas tous…
Pour les fauteuils, entre un manuel utilisée par quelqu'un de sportif, un 
manuel équipé d'une assistance électrique, un "gros" électrique, le même équipé 
d'un respirateur…
Ça change beaucoup.
Tu rajoutes parfois une conduite par un accompagnant plus ou moins habile, avec 
un réglage ± adapté, et c'est partie pour un moment de plaisir ou… une grosse 
galère.
> Si quelqu'un est motivé pour voir avec eux les informations 
> utiles/nécessaires, just do it!
> 
Mon petit doigt me dit qu'il y a quelques pros qui ont travaillé sur le sujet… 
ont-ils un retour à faire sur les tags ?

Le site j'accede est intéressant mais utilise Google Map. On pourrait leur 
suggérer un switch2osm ?

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

Re: [talk-au] Bus stops in Sydney

[cleary]

Hi Sebastian.

I don't think we have permission to use information from 
https://transportnsw.info  so we would need other sources in order to add this 
information in OSM.

However I am not sure that this information is necessary.  Over a few years, I 
have added some bus stops and bus routes and I think the route number is very 
important and stop numbers and names are also helpful but other information not 
so important.

Recently I caught a bus on a minor route. The route was formerly operated by 
Sydney Buses but now appears to be operated by Hillsbus.  It really didn't 
matter to me as a commuter - a bus with the right route number came to my stop 
and took me to where I wanted.   

The NSW Government owns all the routes and now owns all the vehicles. Private 
companies (including corporatised government owned organisations) bid for 
contracts to operate particular services for specified periods. Periodically 
the "operator" (which maintains the vehicles and employs the drivers) may 
change. But it is fairly seamless for passengers. In the past, different  
operators painted vehicles in their own colours but now the NSW Government 
wants all its vehicles the same blue and white colours, so that any differences 
will be minimal when a different operator takes over a route. Older buses still 
have old colours but I understand that the Government's standard colours will 
be used when the vehicles are re-painted. All timetables and information is 
issued by Transport for NSW not by individual companies.

Some buses have signs such as "Operated by Sydney Buses for Transport NSW" or 
"Operated by Busways for NSW Government".  Operators whose names I have seen on 
buses include : Sydney Buses, Transdev, Busways, Hillsbus, Westbus but I think 
there are others and I am not sure who operates all current services. As a 
passenger, it has not really mattered to me and it does not seem to affect 
stops, routes, timetables, or the map.  

Various names are a bit confusing to me even though I have been a regular user 
of public transport. Each new Governemnt sometimes seeks to re-badge something 
as if it is new. I think the name "State Transit Authority" refers to the 
overarching government office which operates the corporatised government-owned 
operators (which I think include Sydney Buses and maybe another operator) and 
will probably be sold off eventually to private owners.

As I said at the start, route numbers are really useful. The numbers and names 
of stops are also helpful. Otherwise I'm not sure what is correct and I'm not 
sure it is necessary for the map.






On Sat, 4 Jul 2020, at 9:33 AM, Sebastian Spiess wrote:
> Hello list,
> 
> it's been a while for me to be active, life got in the way :-) I hope
> everyone is sane and safe.
> 
> 
> Every now and then I add some bus stops around my area. I wanted to add
> operator and network tags as well but am not quite sure.
> 
> 
> What I found so far was:
> 
>     network=Sydney Buses
>     operator=State Transit Authority, Transit Systems West
>     operator=Transport NSW
>     network=Sydney Buses Network
>     network=TNSW - Sydney Buses
>     operator=State Transit Authority
>     operator=Sydney Busses
>     This is as a result of this query https://overpass-turbo.eu/s/VMz
> 
> Now my first point for a source is/was https://transportnsw.info where
> I've learned that NSW is structured in several Regions
> (https://transportnsw.info/regions#/) and Sydney is in the "Sydney and
> surrounds" region (https://transportnsw.info/regions/sydney-surrounds)
> 
> This region has a multitude of operators providing different types of
> services. One the operators page (https://transportnsw.info/operators) I
> can filter for Sydney + Bus. In the big list I can find "State Transit"
> (https://www.transport.nsw.gov.au/state-transit) and by the images of
> the buses there I guess that most of the stops I'm adding are from that
> operator.
> 
> This leads me to believe operator="State Transit" correct. But reading
> on https://www.transport.nsw.gov.au/state-transit/about-us I can learn
> that they are an organisation of 3,500 people with approximately 2,900
> bus operators. Which leaves me again puzzled and unsure.
> 
> So the tags I currently thing are correct are
> 
>     operator=Transport for NSW
> 
>     network=Sydney Buses
> 
> but I'm sure there are others that can shed a better light onto this and
> maybe provide some guidance.
> 
> 
> Cheers,
> 
> Sebastian
> 
> 
> 
> 
> 
> ___
> 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: [Talk-at] Anpassung der Plattentektonik

[Friedrich Volkmann]

On 03.07.20 00:43, Kevin Kofler wrote:

So genau sind die Koordinaten, die wir eintragen, doch in der Regel gar
nicht.

1. Viele Features werden auf Sicht gemappt, d.h., der Mapper schaut
ungefähr, auf welcher Höhe einer Referenzlinie (z.B. Häuserfront) ein POI
ist und klickt dann im Editor ungefähr dort hin.

2. Ebenfalls häufig ist das Abpausen von einer Hintergrundkarte. Auch das
ist gewissermaßen "auf Sicht". Und außerdem sind die Hintergrundkarten auch
nicht immer ganz exakt.

3. Selbst, wenn tatsächlich eine GPS-Messung vorgenommen wird, ist diese mit
einem Meßfehler behaftet.

D.h., ±1m ist ein relativ kleiner Fehler.


Mit einem normalen GPS kriegt man die Toleranz (HDOP) kaum unter 2 m. Das 
ist aber – zumindest in ebenem, freiem Gelände – ein nicht-systematischer 
Fehler, d.h. je mehr Messungen, desto genauer wird es. Dann kann man auch 
auf unter 1 m kommen. Der Kontinentaldrift erzeugt hingegen einen 
systematischen Fehler.


Das meiste wird, wie du eh schon angesprochen hast, nach Hintergrundkarten, 
z.B. Orthofotos und Laserscan, gemappt. Die sind meist schon ziemlich genau 
(Fehler <1m). Für den Höhlenkataster schaue ich mir meistens mehrere 
Luftbilder, Geländeschummerung und Hangneigung an, um möglichst genaue 
Koordinaten zu bekommen. Soviel mal als Gegenbeispiel zur Behauptung, dass 
wir eh alles nicht so genau machen.


Wenn jemand POIs entlang einer Rerenzlinie ausrichtet, dann ist es 
vielleicht erst mal ein Trost, dass wenigstens die Relative Lage zueinander 
stimmt. Aber das ist nicht von Dauer. Sobald die Referenzlinie auf neuen 
Orthofotos woanders zu sehen ist, wird der nächste Mapper die Lage (z.B. des 
Häuserfront oder der Straße) korrigieren, die POIs daneben aber nicht. Das 
war schon damals so, als wir von Yahoo abgezeichnet haben (Fehler > 10 m, 
IIRC). Als dann die Bing-Bilder verfügbar wurden, korrigierte jeder die 
Straßen und keiner die POIS. Der Mistkübel südöstlich der Kreuzung war dann 
auf einmal nordwestlich der Kreuzung, und der Shop auf der einen Seite des 
Häuserblocks, zur Straße X hin, war dann auf der anderen Seite, zur Straße Y 
hin.


Wege werden schon zurechtgerückt, wenn der Unterschied zum Orthofoto nur 1 m 
beträgt. Ich tu das selber auch, obwohl ich weiß, dass das Orthofoto auch 
nicht überall so genau ist und womöglich sogar das alte lagerichtiger war.


Ein Unterschied von 1 m ist auffälliger, als man glauben möchte. Merkaartor 
hat einen Bug, durch den er die basemap-Geländeschummerung um 1-2 m nach W 
versetzt anzeigt. Das fliegen einem die Augen raus, wenn man das sieht. Ich 
zeichne zwar oft von der Schummerung ab, bemühe mich aber, diesen Versatz 
manuell zu kompensieren, indem ich alles um 1-2 m weiter östlich einzeichne. 
Vielleicht kommt dieser Versatz gerade daher, dass Merkaartor bei der 
Umrechnung nicht die richtige Epoche angibt?


Fazit ist also, dass dort, wo man am Luftbild nichts sieht, die Koordinaten 
immer falscher werden, weil sie nie wer korrigieren wird, während dort, wo 
man am Luftbild was sieht, zusätzlich zu absoluten Lagefehlern auch noch 
relative hinzukommen werden.


--
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-us] [openrailwaymap] Self organised session at SotM about Railway tagging in the US tomorrow

[Chuck Sanders]

Agreed!  That felt very productive and useful.

I've wondered if it wouldn't be worth getting a list together specifically
for CA/MX/US rail mappers, since we have so much more in common between the
three than we do different between the countries where rail is concerned.
Plus, I do get the sense that a large majority of the talk-US list may not
have much interest in the rail project, so it'd give us a place to work
through minutiae when it's not a question big enough (with any non-rail
effects) to trouble everyone else.

Chuck

On Sat, Jul 4, 2020 at 6:22 PM Natfoot  wrote:

> Thanks for attending everyone. Real useful and look forward to working
> with you in the future.
>
> Best Regards,
> Nathan P
> email: natf...@gmail.com
>
>
> On Sat, Jul 4, 2020 at 3:16 PM Steve All  wrote:
>
>> Thank you for everybody's participation today, I enjoyed "meeting" or
>> "seeing" you (again), even if it was "hearing" you only!
>>
>> I mentioned an article which classifies light-rail tram-trains into FOUR
>> categories (not three) in an interesting way:
>>
>> https://pedestrianobservations.com/2019/07/31/what-is-light-rail-anyway
>>
>> The gist of the logic for doing this comes from this introduced table of
>> classifications based upon speed of travel in both the center and outlying
>> areas of the line in question:
>>
>> Slow in center  Fast in
>> center
>> Slow in outlying areas  Tramway Subway-surface
>> Fast in outlying areas  Tram-train  Rapid transit
>>
>> (I hope those tabs work for your email display).
>>
>> Interesting article, VERY interesting (and lively — 68 Comments!)
>> Comments Section.  Enjoy.
>>
>> Steve
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-GB] UPRN Locations Map

[Lester Caine]

On 04/07/2020 23:14, Cj Malone wrote:

On Sat, 2020-07-04 at 22:24 +0100, Lester Caine wrote:

What is needed is a means of adding LAYERS of data which can be
managed either via third party data sets, or manual edited using
existing tools to add data that is missing from the narrow view
confined to 'current' objects ...


If I understand you right, I like the idea of this, for example a layer
of bus stops in the UK would be sourced from NapTAN. That layer would
be kept up to date with NapTAN (most bus stops in OSM are a decade old,
unmodified, not validated) and OSM mappers could add
corrections/modifications.
Potentially we could have a line of communication to NapTAN to inform
them of errors in there dataset.

It'll be hard to change some peoples minds, but it's worth discussing.


That is one example and if editing the data can be carried out using 
existing tools then new data sets can be created in a similar way. My 
own tools for handling NLPG data was targeted to allow councils to 
automatically create update data sets as they create new uprn's or 
correct existing ones.


But my own interest is not so much the independent layers like NapTAN 
but being able to update current records with historic details such as 
start_dates which apply to CURRENT objects, but also maintain data that 
has expired due to end_date.


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

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

Re: [Talk-us] [openrailwaymap] Self organised session at SotM about Railway tagging in the US tomorrow

[Natfoot]

Thanks for attending everyone. Real useful and look forward to working with
you in the future.

Best Regards,
Nathan P
email: natf...@gmail.com


On Sat, Jul 4, 2020 at 3:16 PM Steve All  wrote:

> Thank you for everybody's participation today, I enjoyed "meeting" or
> "seeing" you (again), even if it was "hearing" you only!
>
> I mentioned an article which classifies light-rail tram-trains into FOUR
> categories (not three) in an interesting way:
>
> https://pedestrianobservations.com/2019/07/31/what-is-light-rail-anyway
>
> The gist of the logic for doing this comes from this introduced table of
> classifications based upon speed of travel in both the center and outlying
> areas of the line in question:
>
> Slow in center  Fast in
> center
> Slow in outlying areas  Tramway Subway-surface
> Fast in outlying areas  Tram-train  Rapid transit
>
> (I hope those tabs work for your email display).
>
> Interesting article, VERY interesting (and lively — 68 Comments!) Comments
> Section.  Enjoy.
>
> Steve
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-GB] UPRN Locations Map

[Cj Malone]

On Sat, 2020-07-04 at 22:24 +0100, Lester Caine wrote:
> What is needed is a means of adding LAYERS of data which can be
> managed either via third party data sets, or manual edited using
> existing tools to add data that is missing from the narrow view
> confined to 'current' objects ...

If I understand you right, I like the idea of this, for example a layer
of bus stops in the UK would be sourced from NapTAN. That layer would
be kept up to date with NapTAN (most bus stops in OSM are a decade old,
unmodified, not validated) and OSM mappers could add
corrections/modifications.
Potentially we could have a line of communication to NapTAN to inform
them of errors in there dataset.

It'll be hard to change some peoples minds, but it's worth discussing.

Cj


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

Re: [Talk-GB] UPRN Locations Map

[Lester Caine]

On 04/07/2020 20:33, David Woolley wrote:

On 04/07/2020 18:24, Lester Caine wrote:
The current 'OHM' is not a layer that can be easily combined with the 
current 'OSM' layer. Large sections of the current data are simply 
cloned into OHM


I'm not referring to OHM; I'm referring to the main OSM map.  At least 
since September 2012, OSM has the complete back history, and, as far as 
I can see, you can use overpass API to retrieve the map as of any date 
and time since then.


BUT you can't upgrade the data in that history, only access previous 
data without any reference to if it is correct or not. OHM is not a 
solution to add the missing history, or correcting that history which 
was removed because of mistakes. It is simply a record of what was done 
with all it's mistakes ...


What is needed is a means of adding LAYERS of data which can be managed 
either via third party data sets, or manual edited using existing tools 
to add data that is missing from the narrow view confined to 'current' 
objects ...


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

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

Re: [Talk-it-lazio] incontro lunedì

[Martin Koppenhoefer]

sent from a phone

> On 4. Jul 2020, at 23:17, Marcello Pelato  wrote:
> 
> Beh.
> Come non detto. Non posso esserci, sigh!
> Alla prossima



quando potresti?

Ciao Martin 

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

Re: [Talk-it-lazio] incontro lunedì

[Marcello Pelato via Talk-it-lazio]

 Beh.Come non detto. Non posso esserci, sigh!Alla prossima
On Tuesday, June 30, 2020, 01:40:45 PM GMT+2, Marcello Pelato 
 wrote:  
 
  Eheheh :-D"alle 18:00 un pó d'oro ci sarebbe"bèh, non era certo quello che 
intendevo ahahah, ma apprezzo lo sforzo ;-)
Per quell'ora volentieri, ma non posso confermare in questo momento. Incrocio 
le dita.Comunque nel caso concordo giorno, ora, centro e panino..
On Tuesday, June 30, 2020, 01:30:30 PM GMT+2, Martin Koppenhoefer 
 wrote:  
 
 per me va benissimo
CiaoMartin
___
Talk-it-lazio mailing list
Talk-it-lazio@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-lazio

Re: [OSM-talk-be] administrative boundaries - municipalities - gemeenten - communes

[Sander Deryckere]

Hi Pierre,

I mapped a lot of boundaries in West-Flanders, using a tips from Marc
Deridder (user mdri on OSM) who sadly passed away just months after
finishing the Flemish borders.

Marc mapped most of the Flemish borders by using out-of-copyright Ferraris
maps. These could be aligned to the road network in OSM (remember, this was
before the availability of aerial imagery). This is also why the
part-municipalities were mapped before the municipalities: the Ferraris
maps show the old borders.

The borders have actually changed very little in that time. By carefully
defining reference points, and combining maps for both sides of the border,
we could usually get an accuracy of a few meters (good enough for
geocoding, which was the first aim).

Some borders did change in that time. I remember having issues with the
border between Rumbeke and Izegem. But most changes just aligned borders to
distinct features. In the case of Rumbeke and Izegem, the border was
aligned to the E403 motorway.

I hopo this clears up some of the mysteries.

Regards,
Sander

Op za 4 jul. 2020 17:33 schreef joost schouppe :

> Hi Pierre,
>
> When I had some questions about this, I looked deep into the history of
> the boundaries, and got a rather detailed answer from QuercE. But this was
> mostly about part-municipalities in Flanders, so I don't know if it's of
> much use to you.
>
> Op vr 3 jul. 2020 om 15:33 schreef Pierre Parmentier <
> pierrecparment...@gmail.com>:
>
>> Hello,
>>
>> Is anyone still in a position to give the references of the sources
>> available at the time of the introduction into OSM of the communal
>> boundaries in Belgium?
>>
>> Pierre P.
>> ___
>> 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
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] Tag pour les services d'un établissement, quand ils sont adaptés aux fauteuils roulants

[osm . sanspourriel]

Le problème c'est qu'il s'agit de marques.

Les Tiralo ont aussi des Hippocampe

concurrents.

Pour le fait d'avoir une personne accompagnante, ça ne me semble pas
dépendre d'OSM : si c'est dans une structure, ça doit être bon et si
c'est un fauteuil à disposition dans un poste de surveillance c'est sans
sûrement self demerdum. Donc info non pertinente dans OSM ?

Quand je vois le guide de l'agglo de Lorient

ça me laisse perplexe :

Des plages accessibles ou non accessibles, je comprends

Des fauteuils pour aller dans l'eau ou pas je comprends encore.

Mais de tels fauteuils sur une plage non indiquée comme accessible... Le
second doit impliquer le premier.

Je sais que handimap.org trouvait que OSM manquait de tags. Voir leur
FAQ .

Ils ont des trames qui doivent être communes et des pratiques plus
spécifiques.

http://lorient-agglo.handimap.org/ (avec des moteurs d'itinéraires
tenant compte des déficits).

La contribution se fait via des associations (spécialistes) uniquement.

Sans doute parce qu'un valide a du mal à entrer le niveau de richesse de
l'information requise.

Si quelqu'un est motivé pour voir avec eux les informations
utiles/nécessaires, just do it!

Jean-Yvon


Le 04/07/2020 à 09:00, Yves P. - yves.prat...@gmail.com a écrit :

J'ai trouvé un exemple réel : 6 plages vers Narbonnes avec
*wheelchair=yes* + *wheelchair:description*="*Fauteuil Tiralo
disponible au poste de secours*"
https://overpass-turbo.eu/s/VMu

Pour avoir l'expérience d'un système similaire au tiralo
, il peut-être aussi utilisé par des personnes
ayant plutôt des handicaps mentaux ou neurologiques mais qui marche.
Comment décrire ça avec des tags avec des valeurs yes/no ?

Avoir le dispositif adapté c'est bien (tiralo
 pour la baignade, tandemflex
 pour le ski, une escargoline
 pour
le la rando pédestre ou avec un âne…)…
Avoir le sytème de "transfert" c'est mieux ;)
"transfert pour passer du fauteuil de la personne au dispositif adapté
pour faire du sport.

Je me répète, comment décrire ça avec de "simples" tags ?

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

Re: [Talk-GB] UPRN Locations Map

[David Woolley]

On 04/07/2020 18:24, Lester Caine wrote:
The current 'OHM' is not a layer that can be easily combined with the 
current 'OSM' layer. Large sections of the current data are simply 
cloned into OHM


I'm not referring to OHM; I'm referring to the main OSM map.  At least 
since September 2012, OSM has the complete back history, and, as far as 
I can see, you can use overpass API to retrieve the map as of any date 
and time since then.


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

Re: [OSM-talk-fr] Suppression *covid19=*

[osm . sanspourriel]

1) Osmose est ton ami.

2) je pense que le mieux c'est de regarder les principales clés.

3) sinon une expression régulière

le fait si tu es sur une petite zone (ici forma CSV, pas forcément idéal
mais pourquoi pas).

Jean-Yvon

Le 04/07/2020 à 17:50, deuzeffe - opensm@deuzeffe.org a écrit :

Bonjour,

Peu d'équipements de ma commune ont encore des restrictions
d'ouverture/accès adaptées à la crise sanitaire (hors masques et
SHA/GHA, simplement recommandés). Comment supprimer les tags
appropriés sans faire une revue manuelle de chaque POI ? Probablement
par une requête overpass ? Certes, mais laquelle ? À vos claviers !

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

Re: [OSM-talk-fr] Le retour du rendu "QA" et des "layers"

[Christian Quest]

Le 04/07/2020 à 18:04, Thibaud Hulin via Talk-fr a écrit :
Excellente nouvelle ! ça m'a bien aidé pour repérer les imports 
partiels de cadastre en Normandie (liés aux fusions de commune).


Par contre, je ne sais pas si c'est mon navigateur, mais le bleu 
s'arrête en plein milieu de la France, il y a d'autres personnes qui 
ont le problème ?



C'est juste sur le premiers zooms... et je ne sais vraiment pas pourquoi !


--
Christian Quest - OpenStreetMap France


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

Re: [Talk-GB] UPRN Locations Map

[Lester Caine]

On 04/07/2020 12:54, David Woolley wrote:
At the very least data currently live in on a 'current' view should be 
automatically filed to an historic layer when it is replaced


How does this differ from how OSM already works?  You can already create 
versions of the map at any point in its history, except where data has 
been redacted for legal reasons.


The current 'OHM' is not a layer that can be easily combined with the 
current 'OSM' layer. Large sections of the current data are simply 
cloned into OHM anyway. Providing an historic layer which only holds the 
data that has changed over time AND using the same tools to expand on 
that historic data as are used to map current data removes another 
hurdle to maintenance. If third party data such as NLPG can be processed 
to provide it's data as another layer which can then be combined in the 
one view then it removes the need to simply import large data sets. One 
simply uses which set of layers you want ...


Of cause the other approach is simply merge all available data ... past, 
present and future ... into the one humungus database and navigate the 
problems of maintaining potentially thousands of data sets in sync with 
the 'master' copy.


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

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

Re: [Talk-GB] Solar Power mapping update Q2 2020

[Dan S]

Hi all

That's great news. By the way, I have some regions to propose, if
anyone would like to be steered:

With my solar PV colleagues, we've discussed targeting a couple of
specific regions. We're looking at the Midlands (because so much good
mapping has happened there already) - but also the area around Exeter,
because there's quite a lot of "reverse flow" (i.e. solar generation)
in that region, and it's a useful case-study area for people working
with the National Grid ESO.

Exeter itself has been mapped to a good extent (30%), but it and its
surrounding areas could take more: Teignbridge (1%), Mid Devon (22%),
East Devon (4%). If anyone fancies looking over those regions, it
could be v beneficial.

Really great seeing all this mapping. I'm hoping to be able to publish
some academic analysis of it all, soonish. - I'll certainly let you
know when I've done so!

Best
Dan

Op do 2 jul. 2020 om 19:16 schreef Gregory Williams
:
>
> Thanks Jerry, and thanks to everyone that's continued to contribute
> more coverage.
>
> The next quarter's update to the FiT register should be published in
> the next few days. So I hope to find time to update the site to use
> that soon.
>
> I continue to be amazed at the steady progress in the coverage. Though,
> as you say, there are quite a few areas where the imagery either just
> isn't clear enough to untangle the ambiguities, or is clear but isn't
> recent enough.
>
> Personally, I've recently been trying to concentrate on a mixture of
> areas with less than 10% coverage, and on the lightly-mapped LSOA
> hotspots that my tool picked out.
>
> Cheers,
>
> Gregory
>
> On Thu, 2020-07-02 at 18:56 +0100, SK53 wrote:
> > We passed a couple of milestones a few days ago:
> > 20% of FIT totals
> > 170k individual panels mapped (excluding those in solar farms)
> > In terms of coverage there are now well over 50 LAs (all in England &
> > Wales) with more than 50% of solar installations mapped, with around
> > 10 exceeding 80%. Areas with good coverage are:
> > Scottish Central Belt: helped no doubt by more atomic data much of
> > the Central Belt is around 20% mapped.
> > North-East (former Tyne & Wear): Newcastle, Gateshead, Sunderland and
> > North & South Tyne.
> > North Wales: Conwy, Flint, Denbigh & Wrexham. Most panels in the
> > first three are in the coastal resort towns, but reasonable rural
> > coverage.
> > North West: recent activity has been around Preston, Blackburn Wigan
> > and Chorley.
> > East Midlands: mainly Leics & Notts. Improved & recent imagery for
> > Leicester made a huge difference.
> > West Midlands: Warwickshire, Worcestershire & Herefordshire are
> > roughly in the 20-30% zone. ALso extending into the South Wales
> > valleys. brianboru's detailed mapping in the latter is another good
> > index of rural coverage.
> > South Coast: Bournemouth area & Southampton, all at over 50%
> > More rural areas continue to be challenging: older imagery which is
> > often difficult to interpret doesn't help. I've experimented in
> > places where every building is already mapped by stepping through
> > each building, but still one may only find 20% of the number in FIT.
> >
> > London and immediately adjacent areas also have relatively little
> > mapped. Imagery can be a problem, but also finding panels in older
> > and/or larger housing with more complex roof shapes is hard.
> >
> > One thing I'm continually amazed at is how many places have buildings
> > mapped, which is very helpful for this task. However in a couple of
> > places: Ribble Valley & Leicester - it is clear that better imagery
> > would allow existing building outlines to be improved, but also that
> > plenty of buildings have been extended, demolished or replaced. This
> > type of activity lends itself to combined work using tools such as
> > Tasking Manager or MapRoulette and might be worth considering in the
> > future for a quarterly project.
> >
> > There's still no shortage of places where a lot of panels can be
> > mapped quickly, although more systematic mapping of a single LA often
> > requires a couple of passes over imagery.
> >
> > Looking forward to achieving the next milestones of 200k & 25%.
> >
> > Jerry
> >
> > Personally, I'm concentrating on areas adjacent to the existing well-
> > mapped (50%+) areas with the aim of extending these areas.
> >
> > ___
> > Talk-GB mailing list
> > Talk-GB@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-gb
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [Talk-GB] UPRN Locations Map

[Nick]

Hi Mark

I was wondering in the future if street names etc. could be derived from 
Mapillary (attribution source=Mapillary) where images exist?


Cheers

Nick

On 04/07/2020 12:02, Mark Goodge wrote:



On 04/07/2020 06:16, Kai Michael Poppe - OSM wrote:


So, a few months ago I stumbled upon a note
(https://www.openstreetmap.org/note/2158104#map=19/51.49829/-0.32762)
that StreetComplete left saying, that the street couldn't be given a
name because there's none shown.

Back then, I used streetmap.co.uk
(https://www.streetmap.co.uk/map.srf?X=516161=179063=Y=106) in
hopes to finding something - but only got "FAI RD." which - to me -
makes no sense.

Also, using https://os.openstreetmap.org/ makes it look like that's just
an access path to houses around it, which is (IMHO) not entirely true as
the way directly linking Southdown Av. and Boston Rd. clearly is
publicly accessible.

Now, using the above mentioned map
(https://osm.mathmos.net/addresses/uprn/#19/51.4983/-0.3279) I now know,
that this street has the UPRN ID 12145988.


That may not be the UPRN of the path or street. It may be the UPRN of 
the open space that the path runs through. The path is more likely to 
have a USRN (unique street reference number) than a UPRN.


To find the USRN of the path, you need to use the lookup tables 
supplied by OS. Doing that, we find that the associated USRN is 20602512.


Now, there's no open data source which will directly tell you the name 
of a USRN (at least, not until we start putting them into OSM). The 
long way of doing so is to find the matching LineString in OS OpenMap 
Local, and see what name it has there.


However, it can be done directly via a non-open source. If you go to 
https://www.findmystreet.co.uk/map and zoom in on the location, then 
click the street to bring up the USRN details, it will give the name 
(and also confirm that the USRN from the OS lookup table is correct). 
Or use the search box and search for USRN 20602512.


From an OSM point of view, that would normally be a dead end. Even if 
you can view the information on a non-open source, you can't 
incorporate it into OSM. However, in this case, we already have an 
abbreviated name from an open source. So all we are learning from the 
closed source is the full text of the abbreviation. Whether that makes 
it acceptable to include the full name into OSM is a matter of debate. 
I'll leave that decision up to others, but, for reference, the name of 
the street is Fairfield Road.


Mark

___
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] Le retour du rendu "QA" et des "layers"

[Thibaud Hulin via Talk-fr]

Excellente nouvelle ! ça m'a bien aidé pour repérer les imports partiels 
de cadastre en Normandie (liés aux fusions de commune).


Par contre, je ne sais pas si c'est mon navigateur, mais le bleu 
s'arrête en plein milieu de la France, il y a d'autres personnes qui ont 
le problème ?


(Et je ne connaissais pas cadastre.damsy.net, je faisais toutes les 
fusions comme un vieux dinosaure ... :( )


Kioska Journo

Le 04/07/2020 à 17:36, Christian Quest a écrit :
Il s'agit du rendu qui compare les données OSM avec le carroyage de la 
population de l'INSEE.


Le principe:

- l'INSEE publie la population répartie sur tout le territoire par 
carreaux de 200m de côté.


- on doit donc trouver à proximité d'un carreau des bâtiments et des 
routes...


Plus d'info ici:

https://wiki.openstreetmap.org/wiki/FR:Serveurs/tile.openstreetmap.fr#Couche_.22Zones_.C3.A0_mapper.22 




Jocelyn a aussi remis en place les couches de 
"layers.openstreetmap.fr", avec les limites admin, les voies sans nom, 
etc...



Tout est visible sur 
http://layers.openstreetmap.fr/?zoom=8=47.7062=2.77204=000B00FFTFF




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

[OSM-talk-ie] Changeset needs reversal

[Colm Moore]

Hi,

https://www.openstreetmap.org/changeset/87511278#map=13/54.0812/-7.4201

Most of / all this changeset needs reversal, especially the N3, where the 
bypass was mapped. I would be grateful if someone could help.

Colm

---
Never doubt that a small group of thoughtful, committed citizens can change the 
world. Indeed, it is the only thing that ever has. Margaret Mead
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [OSM-talk-fr] Le retour du rendu "QA" et des "layers"

[deuzeffe]

Le 04/07/2020 à 17:47, Yves P. a écrit :


J'ai regardé des zones bleus : c'est bluffant quand on affiche le cadastre, il 
manque plein de bâtiments


Heureusement, il y a Danette^W https://cadastre.damsy.net !

HTH
--
deuzeffe

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

[OSM-talk-fr] Suppression *covid19=*

[deuzeffe]

Bonjour,

Peu d'équipements de ma commune ont encore des restrictions 
d'ouverture/accès adaptées à la crise sanitaire (hors masques et 
SHA/GHA, simplement recommandés). Comment supprimer les tags appropriés 
sans faire une revue manuelle de chaque POI ? Probablement par une 
requête overpass ? Certes, mais laquelle ? À vos claviers !


Merci pour votre aide.
--
deuzeffe

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

Re: [OSM-talk-fr] Le retour du rendu "QA" et des "layers"

[Yves P.]

> Il s'agit du rendu qui compare les données OSM avec le carroyage de la 
> population de l'INSEE.
> 
> Le principe:
> - l'INSEE publie la population répartie sur tout le territoire par carreaux 
> de 200m de côté.
> - on doit donc trouver à proximité d'un carreau des bâtiments et des routes...

J'ai regardé des zones bleus : c'est bluffant quand on affiche le cadastre, il 
manque plein de bâtiments

Au hazard : 
http://layers.openstreetmap.fr/?zoom=18=47.18753=1.11794=000B00TFTFF

Il y a du boulot

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

[OSM-talk-fr] Le retour du rendu "QA" et des "layers"

[Christian Quest]

Il s'agit du rendu qui compare les données OSM avec le carroyage de la 
population de l'INSEE.


Le principe:

- l'INSEE publie la population répartie sur tout le territoire par 
carreaux de 200m de côté.


- on doit donc trouver à proximité d'un carreau des bâtiments et des 
routes...


Plus d'info ici:

https://wiki.openstreetmap.org/wiki/FR:Serveurs/tile.openstreetmap.fr#Couche_.22Zones_.C3.A0_mapper.22


Jocelyn a aussi remis en place les couches de "layers.openstreetmap.fr", 
avec les limites admin, les voies sans nom, etc...



Tout est visible sur 
http://layers.openstreetmap.fr/?zoom=8=47.7062=2.77204=000B00FFTFF


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-be] administrative boundaries - municipalities - gemeenten - communes

[joost schouppe]

Hi Pierre,

When I had some questions about this, I looked deep into the history of the
boundaries, and got a rather detailed answer from QuercE. But this was
mostly about part-municipalities in Flanders, so I don't know if it's of
much use to you.

Op vr 3 jul. 2020 om 15:33 schreef Pierre Parmentier <
pierrecparment...@gmail.com>:

> Hello,
>
> Is anyone still in a position to give the references of the sources
> available at the time of the introduction into OSM of the communal
> boundaries in Belgium?
>
> Pierre P.
> ___
> 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-GB] UPRN Locations Map

[Kai Michael Poppe - OSM]

Hi Marc,

Thanks for the reply. I'll make it my task to find an out of date copyright map 
that brings the full name, wherever I might find it :)

Have a great weekend!

Kai

Am 4. Juli 2020 13:02:59 MESZ schrieb Mark Goodge :
>
>
>On 04/07/2020 06:16, Kai Michael Poppe - OSM wrote:
>> 
>> So, a few months ago I stumbled upon a note
>> (https://www.openstreetmap.org/note/2158104#map=19/51.49829/-0.32762)
>> that StreetComplete left saying, that the street couldn't be given a
>> name because there's none shown.
>> 
>> Back then, I used streetmap.co.uk
>> (https://www.streetmap.co.uk/map.srf?X=516161=179063=Y=106) in
>> hopes to finding something - but only got "FAI RD." which - to me -
>> makes no sense.
>> 
>> Also, using https://os.openstreetmap.org/ makes it look like that's just
>> an access path to houses around it, which is (IMHO) not entirely true as
>> the way directly linking Southdown Av. and Boston Rd. clearly is
>> publicly accessible.
>> 
>> Now, using the above mentioned map
>> (https://osm.mathmos.net/addresses/uprn/#19/51.4983/-0.3279) I now know,
>> that this street has the UPRN ID 12145988.
>
>That may not be the UPRN of the path or street. It may be the UPRN of 
>the open space that the path runs through. The path is more likely to 
>have a USRN (unique street reference number) than a UPRN.
>
>To find the USRN of the path, you need to use the lookup tables supplied 
>by OS. Doing that, we find that the associated USRN is 20602512.
>
>Now, there's no open data source which will directly tell you the name 
>of a USRN (at least, not until we start putting them into OSM). The long 
>way of doing so is to find the matching LineString in OS OpenMap Local, 
>and see what name it has there.
>
>However, it can be done directly via a non-open source. If you go to 
>https://www.findmystreet.co.uk/map and zoom in on the location, then 
>click the street to bring up the USRN details, it will give the name 
>(and also confirm that the USRN from the OS lookup table is correct). Or 
>use the search box and search for USRN 20602512.
>
> From an OSM point of view, that would normally be a dead end. Even if 
>you can view the information on a non-open source, you can't incorporate 
>it into OSM. However, in this case, we already have an abbreviated name 
>from an open source. So all we are learning from the closed source is 
>the full text of the abbreviation. Whether that makes it acceptable to 
>include the full name into OSM is a matter of debate. I'll leave that 
>decision up to others, but, for reference, the name of the street is 
>Fairfield Road.
>
>Mark
>
>___
>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] Euskal Herria

[Maël REBOUX]

Bonjour,

Je suis bien moins calé que Christian ROGEL (et d’autres) sur tout ça donc je 
vais seulement donner mon avis.

Je trouve également que le rajout systématique de « (Euskal Herria) » sur la 
relation https://www.openstreetmap.org/relation/11107464/ 
 n’est pas très heureux même 
si l’intention de défense / promotion de la langue basque est louable.

Ce qui est inhabituel et qui attire l’œil c’est plus les name avec 2 idiomes. 
Ex : les parcs régionaux 
https://www.openstreetmap.org/relation/6594547#map=12/43.0418/-2.8091 


MAIS le basque a un statut de co-officialité côté espagnol (les veinards) donc 
ahma ils ne sont pas illégitimes à procéder de la sorte même si ça alourdit 
considérablement le rendu cartographique standard. Question d’habitude 
également.

Je vais me cantonner à promouvoir le rendu basque exclusif et le signaler à 
Hartz Beltza 

Maël


> Le 3 juil. 2020 à 11:36, Yves P.  a écrit :
> 
>> Nul part on ne met le nom en langue native entre parenthèse : ça fout le 
>> bordel !
>> 
> Faut-pas titiller les bretons sur les questions de langues :D
> 
>> Sinon une relation boundary sans boundary= c'est de la branlette 
>> intellectuelle.
>> 
> 
> Pour la branlette j'ai la primeur :P
> 
> J'espère que tu sera mieux compris que moi ;)
> 
> __
> Yves
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [Talk-GB] UPRN Locations Map

[SK53]

I've tried to match UPRNs to buildings 1:1 in Nottingham and therefore
provide an address lookup. Here's the first stab of 35 k objects:
https://raw.githubusercontent.com/SK53/osm_uprn/master/ng_osm_uprn_lu.csv

Jerry

On Sat, 4 Jul 2020 at 12:28, Mark Goodge  wrote:

>
>
> On 04/07/2020 12:16, Stephen Knox wrote:
> > I don't think there is value in bringing in the points themselves but
> > I think there definitely is value in tagging existing buildings /
> > locations with the UPRN where it is incontrovertible - e.g. a single
> > unit house. This is the vast majority of the buildings in the UK, if
> > not the addresses. There are difficulties to overcome with multiple
> > unit buildings, that probably needs a lot of further thought and
> > possibly further open data releases to do properly, which may appear
> > eventually. How historical values are managed is also a consideration
> > to deal with.
>
> I agree. I think we have to bear in mind that UPRNs will become
> increasingly important to map users, and having them in the tag data
> will be useful. If it's a known fact about a building, then it does no
> harm, and will be potentially beneficial, to tag the building with the
> UPRN.
>
> But we do need to be wary of historic data and overlapping UPRNs. Unless
> we have incontrovertible local knowledge from a compatible source, then
> we shouldn't add a UPRN tag if the open data is in any way ambiguous.
>
> The same applies to USRNs. Where we can unambiguously match a road or
> street on OSM to a USRN, then we should add the tag. But only if we can
> be certain.
>
> > Arguably of more use for OSM for the here and now is the change to
> > the licence of the UK Land Registry INSPIRE polygons to OGL, which I
> > haven't seen much or any discussion of on this list. This means that
> > we now have an authoritative reference for boundaries and can use
> > that to alter and check geometries of things like semi-detached house
> > boundaries, gardens, hedges
> > etc.https://www.gov.uk/guidance/inspire-index-polygons-spatial-data.
>
> I agree with that, too.
>
> Mark
>
> ___
> 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-at] Anpassung der Plattentektonik

[ScubbX]

In der Geodäsie werden zur Vermeidung von Plattendrifts Epochen
angegeben bzw nicht das WGS84 Ellipsoid als Referenz benutzt, sondern,
wie im Fall von Europa oft, ein ETRS89 System. Dieses ETRS89 benutzt das
sogenannte GRS80 Ellipsoid, welches dem WGS84 sehr ähnlich ist.
Allerdings ist das System auf der Europöischen Platte verankert und ist
so für Europa sehr stabil. Dafür ist es für den Rest der Welt über die
Zeit ungenauer.

Die Erde ist halt einfach keine Kugel, kein Ellipsoid,und auch nicht
statisch. :-D

Neue Versionen der Proj Library unterstützen Geodätische Reprojektionen
mit so genauen Angaben : https://proj.org/usage/transformation.html
(Proj4 hat immer noch via WGS84 als gemeinsamen Nenner transformiert,
was zwangsweise geodätische Ungenauigkeiten erzeugt hat).

Sollten Verschiebungen einmal in die OSM-Datenbank eingerechnet werden,
denke ich, dass das Bereitstellen einer optionalen Transformationsfläche
bei der Abfrage der Daten sinnvoller ist, als die Originaldaten selber
zu verändern (dafür gibt es bereits bestehende Verfahren -> zBsp. "NTv2"
Grids).
Aber das hat alles seine eigenen Für- und Wider .



Am 03.07.20 um 01:07 schrieb grubernd:
> On 03.07.20 00:43, Kevin Kofler wrote:
>> So genau sind die Koordinaten, die wir eintragen, doch in der Regel gar
>> nicht.
>
>
> Sehe ich auch so. Alles was der normale Mapper zur Verfügung hat ist
> ungenauer als die Drift von vielen vielen Jahren. Vorallem der heilige
> Gral GPS. Australien vielleicht ausgenommen. Aber dafür ist deren Land
> auch viel grösser und da kannst du froh sein, wenn die relevanten
> Elemente und Navigationspunkte überhaupt eingetragen sind.
>
> Alles was nicht von Geodäten mit dem entsprechenden Werkzeug
> produziert wurde ist also aus meiner Sicht irrelevant was solche
> Feinheiten angeht.
>
> Und bleiben wir pragmatisch in der Verwendung der Daten .. auf Grund
> einer Karte eine Blindnavigation zu machen ist sowieso nur Fantasie.
> In der Genauigkeit arbeiten nicht einmal autonome Fahrsysteme. Die
> haben nämlich auch feststellen müssen, dass eine Echtzeitverarbeitung
> der _aktuellen_ Situation viel wichtiger ist als eine exakte Karte -
> egal wie aktuell die auch erstellt sein mag.
>
> Nettes Gedankenspiel, aber ich finde dabei kann man es auch belassen.
>
>
> grüsse,
> grubernd
>
>
> ___
> 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] UPRN Locations Map

[David Woolley]

On 04/07/2020 11:45, Lester Caine wrote:
At the very least data currently live in on a 'current' view should be 
automatically filed to an historic layer when it is replaced


How does this differ from how OSM already works?  You can already create 
versions of the map at any point in its history, except where data has 
been redacted for legal reasons.


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

Re: [Talk-GB] UPRN Locations Map

[Ed Loach]

I'd suggest only add it to buildings where the address already exists and there 
is a one to one mapping, so we can use unmatched values to see where needs 
surveying.

Ed

Get Outlook for Android


From: Stephen Knox 
Sent: Saturday, July 4, 2020 12:16:38 PM
To: talk-gb@openstreetmap.org 
Subject: [Talk-GB] UPRN Locations Map


On 04/07/2020 08:51, Stephen Colebourne wrote:
> I'm not convinced this data should be pulled into OSM. It would add a
> lot of clutter that users would be tempted to move around or delete. In
> areas like mine where I've added thousands of buildings and addresses
> from surveys, it would be making matters worse not better. It would be a
> disincentive to adding more buildings with addresses as the additional
> nodes would get in the way of editing, and because they represent a semi
> random set of things. Because the dataset is fixed I would think it
> should be a layer used alongside OSM by those tools that think it adds
> value. Ideally, OSM itself should support layers, but AFAIK it doesn't.

I don't think there is value in bringing in the points themselves but I think 
there definitely is value in tagging existing buildings / locations with the 
UPRN where it is incontrovertible - e.g. a single unit house. This is the vast 
majority of the buildings in the UK, if not the addresses. There are 
difficulties to overcome with multiple unit buildings, that probably needs a 
lot of further thought and possibly further open data releases to do properly, 
which may appear eventually. How historical values are managed is also a 
consideration to deal with.

UPRNs will not bring any obvious value initially, but will gradually make OSM 
much more useful for the commercial sector, hopefully for everyone's benefit, 
as they can match IDs from proprietary datasets with Open OSM data, and it also 
enables OSM to be used an an authoritative ID for every building - neither 
postcodes nor addresses do that.

Arguably of more use for OSM for the here and now is the change to the licence 
of the UK Land Registry INSPIRE polygons to OGL, which I haven't seen much or 
any discussion of on this list. This means that we now have an authoritative 
reference for boundaries and can use that to alter and check geometries of 
things like semi-detached house boundaries, gardens, hedges etc. 
https://www.gov.uk/guidance/inspire-index-polygons-spatial-data.

Stephen


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

Re: [Talk-GB] UPRN Locations Map

[Mark Goodge]

On 04/07/2020 12:16, Stephen Knox wrote:

I don't think there is value in bringing in the points themselves but
I think there definitely is value in tagging existing buildings /
locations with the UPRN where it is incontrovertible - e.g. a single
unit house. This is the vast majority of the buildings in the UK, if
not the addresses. There are difficulties to overcome with multiple
unit buildings, that probably needs a lot of further thought and
possibly further open data releases to do properly, which may appear
eventually. How historical values are managed is also a consideration
to deal with.


I agree. I think we have to bear in mind that UPRNs will become 
increasingly important to map users, and having them in the tag data 
will be useful. If it's a known fact about a building, then it does no 
harm, and will be potentially beneficial, to tag the building with the UPRN.


But we do need to be wary of historic data and overlapping UPRNs. Unless 
we have incontrovertible local knowledge from a compatible source, then 
we shouldn't add a UPRN tag if the open data is in any way ambiguous.


The same applies to USRNs. Where we can unambiguously match a road or 
street on OSM to a USRN, then we should add the tag. But only if we can 
be certain.



Arguably of more use for OSM for the here and now is the change to
the licence of the UK Land Registry INSPIRE polygons to OGL, which I
haven't seen much or any discussion of on this list. This means that
we now have an authoritative reference for boundaries and can use
that to alter and check geometries of things like semi-detached house
boundaries, gardens, hedges
etc.https://www.gov.uk/guidance/inspire-index-polygons-spatial-data.


I agree with that, too.

Mark

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

[Talk-GB] UPRN Locations Map

[Stephen Knox]

On 04/07/2020 08:51, Stephen Colebourne wrote:
>* I'm not convinced this data should be pulled into OSM. It would add a
*>* lot of clutter that users would be tempted to move around or delete. In
*>* areas like mine where I've added thousands of buildings and addresses
*>* from surveys, it would be making matters worse not better. It would be a
*>* disincentive to adding more buildings with addresses as the additional
*>* nodes would get in the way of editing, and because they represent a semi
*>* random set of things. Because the dataset is fixed I would think it
*>* should be a layer used alongside OSM by those tools that think it adds
*>* value. Ideally, OSM itself should support layers, but AFAIK it doesn't.*

I don't think there is value in bringing in the points themselves but
I think there definitely is value in tagging existing buildings /
locations with the UPRN where it is incontrovertible - e.g. a single
unit house. This is the vast majority of the buildings in the UK, if
not the addresses. There are difficulties to overcome with multiple
unit buildings, that probably needs a lot of further thought and
possibly further open data releases to do properly, which may appear
eventually. How historical values are managed is also a consideration
to deal with.

UPRNs will not bring any obvious value initially, but will gradually
make OSM much more useful for the commercial sector, hopefully for
everyone's benefit, as they can match IDs from proprietary datasets
with Open OSM data, and it also enables OSM to be used an an
authoritative ID for every building - neither postcodes nor addresses
do that.

Arguably of more use for OSM for the here and now is the change to the
licence of the UK Land Registry INSPIRE polygons to OGL, which I
haven't seen much or any discussion of on this list. This means that
we now have an authoritative reference for boundaries and can use that
to alter and check geometries of things like semi-detached house
boundaries, gardens, hedges etc.
https://www.gov.uk/guidance/inspire-index-polygons-spatial-data.

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

Re: [Talk-GB] UPRN Locations Map

[Mark Goodge]

On 04/07/2020 06:16, Kai Michael Poppe - OSM wrote:


So, a few months ago I stumbled upon a note
(https://www.openstreetmap.org/note/2158104#map=19/51.49829/-0.32762)
that StreetComplete left saying, that the street couldn't be given a
name because there's none shown.

Back then, I used streetmap.co.uk
(https://www.streetmap.co.uk/map.srf?X=516161=179063=Y=106) in
hopes to finding something - but only got "FAI RD." which - to me -
makes no sense.

Also, using https://os.openstreetmap.org/ makes it look like that's just
an access path to houses around it, which is (IMHO) not entirely true as
the way directly linking Southdown Av. and Boston Rd. clearly is
publicly accessible.

Now, using the above mentioned map
(https://osm.mathmos.net/addresses/uprn/#19/51.4983/-0.3279) I now know,
that this street has the UPRN ID 12145988.


That may not be the UPRN of the path or street. It may be the UPRN of 
the open space that the path runs through. The path is more likely to 
have a USRN (unique street reference number) than a UPRN.


To find the USRN of the path, you need to use the lookup tables supplied 
by OS. Doing that, we find that the associated USRN is 20602512.


Now, there's no open data source which will directly tell you the name 
of a USRN (at least, not until we start putting them into OSM). The long 
way of doing so is to find the matching LineString in OS OpenMap Local, 
and see what name it has there.


However, it can be done directly via a non-open source. If you go to 
https://www.findmystreet.co.uk/map and zoom in on the location, then 
click the street to bring up the USRN details, it will give the name 
(and also confirm that the USRN from the OS lookup table is correct). Or 
use the search box and search for USRN 20602512.


From an OSM point of view, that would normally be a dead end. Even if 
you can view the information on a non-open source, you can't incorporate 
it into OSM. However, in this case, we already have an abbreviated name 
from an open source. So all we are learning from the closed source is 
the full text of the abbreviation. Whether that makes it acceptable to 
include the full name into OSM is a matter of debate. I'll leave that 
decision up to others, but, for reference, the name of the street is 
Fairfield Road.


Mark

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

Re: [Talk-GB] UPRN Locations Map

[Lester Caine]

On 04/07/2020 08:51, Stephen Colebourne wrote:
I'm not convinced this data should be pulled into OSM. It would add a 
lot of clutter that users would be tempted to move around or delete. In 
areas like mine where I've added thousands of buildings and addresses 
from surveys, it would be making matters worse not better. It would be a 
disincentive to adding more buildings with addresses as the additional 
nodes would get in the way of editing, and because they represent a semi 
random set of things. Because the dataset is fixed I would think it 
should be a layer used alongside OSM by those tools that think it adds 
value. Ideally, OSM itself should support layers, but AFAIK it doesn't.


That about sums it up. The plans themselves may be a starting point 
where there is nothing, but ALL that needs importing are the references 
being added to existing objects in OSM. As you say, the data in the NLPG 
data set is 'read only' and so anybody 'editing mistakes' may not 
understand that it is displaying what is the 'legal' situation on the 
ground. Any mistakes need to be reported to the right authority.


That OSM does not support layers is now a major stumbling block. At the 
very least data currently live in on a 'current' view should be 
automatically filed to an historic layer when it is replaced, but with 
the growing volume of other data sources with detailed graphical 
content, being able to combine layers of data should be a high priority. 
There should then be no need to import snapshots of those managed data 
sets and have to maintain mechanisms to keep the two in sync. Just use 
the raw data direct in parallel with the unique OSM data.


It is worth pointing out that unless something has changed drastically 
in the last few years, then the range of fine detail contained in the 
NLPG varies vastly between the various council sources. I think I have 
seen comments about 'only having a node' and not providing enough detail 
to identify different references. Certainly 10 years ago only a small 
number of councils actually had plans of the extent of each council tax 
parcel and other fine detail. Most just had a node somewhere in the 
right area. Many were reliant on paid services from OS for map data and 
so did not have a licence to copy that data over. HOPEFULLY today that 
particular problem has been resolved.


I've not had time yet to look at just what is available against the now 
somewhat out of data local extracts I have from the original NLPG dataset.


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

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

Re: [Talk-GB] UPRN Locations Map

[SK53]

The new Leicester Coronavirus Regulations

provide some interesting test data, ostensibly under a Open Government
Licence, of 24 pages of postcodes and what are obviously individual
properties where postcodes are split by the boundary captured by querying
UPRNs (telephone & post boxes are a useful clue). For instance Welford Road
in Wigston (on p. 34) corresponds to this area
 on Robert's
site. Postcode LE18 3TE seems to extend from the junction of Welford Road
with Guthlaxton Lane down to the Navigation at Kilby Bridge. I've just
added the telephone (from this Mapillary
 image) which is
presumably UPRN 10025590850.

Given this looks to have been created by querying for objects via MasterMap
or similar I imagine the actual data is in practice covered by GeoPlace &
OSGB restrictions.

Nonetheless there are a few intriguing things mentioned which I cant locate
on OSM, including Lime Delph Road (which is probably the frontage road on
the new housing estate with unnamed road on the E). Nor is the nursery
obvious.

Jerry

On Sat, 4 Jul 2020 at 09:48, Jez Nicholson  wrote:

> From Wikidata, https://m.wikidata.org/wiki/Property:P8399 if you query
> the UK Flood service with the UPRN you can see more detail on the property
>
> On Sat, 4 Jul 2020, 08:52 Stephen Colebourne, 
> wrote:
>
>> I'm not convinced this data should be pulled into OSM. It would add a lot
>> of clutter that users would be tempted to move around or delete. In areas
>> like mine where I've added thousands of buildings and addresses from
>> surveys, it would be making matters worse not better. It would be a
>> disincentive to adding more buildings with addresses as the additional
>> nodes would get in the way of editing, and because they represent a semi
>> random set of things. Because the dataset is fixed I would think it should
>> be a layer used alongside OSM by those tools that think it adds value.
>> Ideally, OSM itself should support layers, but AFAIK it doesn't.
>> Stephen
>> PS. Thanks for the slippy map!
>>
>> On Thu, 2 Jul 2020, 17:38 Robert Whittaker (OSM lists), <
>> robert.whittaker+...@gmail.com> wrote:
>>
>>> I'm not completely sure if/how we can best make use of the new OS
>>> OpenData (UPRNs, USRNs and related links) in OpenStreetMap, but as a
>>> first step I've set up a quick slippy map with the UPRN locations
>>> shown:
>>>
>>> https://osm.mathmos.net/addresses/uprn/ (zoom in to level 16 to show
>>> the data)
>>>
>>> The UPRN dataset literally just contains the UPRN number and its
>>> coordinates (both OS National Grid and WGS lat/lon). There are some
>>> additional linking datasets that link these ids to other ids (e.g.
>>> USRNs, TOIDs). But no address information is available directly. (You
>>> may be able to get street names by matching to OS Open Roads via TOIDs
>>> though. Coupled with Code-Point Open, you might be able to assign
>>> quite a few postcodes in cases where there's only one unit for a whole
>>> street.)
>>>
>>> The UPRN data has already helped me find a mapping error I made
>>> locally though -- it looks like I'd accidentally missed drawing a
>>> house outline from aerial imagery, and also classified a large garage
>>> a few doors down as a house. The two errors cancelled out when the
>>> houses were numbered sequentially, so I didn't notice until now. Today
>>> though I spotted a UPRN marker over some blank space on the map, and
>>> no marker over the mapped house that's probably a garage.
>>>
>>> Now a few initial thoughts on the data that I've explored so far:
>>>
>>> I believe that the UPRNs are assigned by local authorities, so
>>> conventions may vary from place to place. I don't know who actually
>>> assigns the coordinates (authority or OS). Looking at those for rows
>>> of houses around me, they don't seem to have been automatically given
>>> coordinates from the house footprint, it looks more like someone
>>> manually clicking on a map.
>>>
>>> The UPRN dataset should include all addressable properties. It is also
>>> ahead of reality in some places, as it includes locations for houses
>>> on a new development near me that have yet to be built yet. For blocks
>>> of apartments/flats, the UPRN nodes may all have the same coordinates
>>> or may be displaced from each other, possibly in an artificial manner.
>>>
>>> Other objects also appear to have UPRNs. Likely things I've noticed so
>>> far include: car parks, post boxes, telephone boxes (even after
>>> they've been removed), electricity sub-stations, roads and recorded
>>> footpaths (the UPRN locations seem to be at one end of the street, so
>>> usually lie at a junction), recreation grounds / play areas,
>>> floodlight poles (around sports pitches), and allotments. There's no
>>> information about the object type in the UPRN data unfortunately.
>>>
>>> Anyway, 

Re: [OSM-talk-fr] GoGoCarto --- demande d'information

[Yves P.]

> https://cartodb-basemaps-a.global.ssl.fastly.net/light_all/10/520/374.png 
> 
> Je ne connais pas ces tuiles, et vous ?

Comme me l'a fait remarqué Jean-Yvon :), c'est Carto 
.
Et les données proviennent d'OSM : 
https://carto.com/help/working-with-data/attribution/

Les autres fonds de plan disponibles dans gogocarto proviennent d'OSM
__
Yves

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

[talk-au] Bus stops in Sydney

[Sebastian Spiess]

Hello list,

it's been a while for me to be active, life got in the way :-) I hope
everyone is sane and safe.


Every now and then I add some bus stops around my area. I wanted to add
operator and network tags as well but am not quite sure.


What I found so far was:

    network=Sydney Buses
    operator=State Transit Authority, Transit Systems West
    operator=Transport NSW
    network=Sydney Buses Network
    network=TNSW - Sydney Buses
    operator=State Transit Authority
    operator=Sydney Busses
    This is as a result of this query https://overpass-turbo.eu/s/VMz

Now my first point for a source is/was https://transportnsw.info where
I've learned that NSW is structured in several Regions
(https://transportnsw.info/regions#/) and Sydney is in the "Sydney and
surrounds" region (https://transportnsw.info/regions/sydney-surrounds)

This region has a multitude of operators providing different types of
services. One the operators page (https://transportnsw.info/operators) I
can filter for Sydney + Bus. In the big list I can find "State Transit"
(https://www.transport.nsw.gov.au/state-transit) and by the images of
the buses there I guess that most of the stops I'm adding are from that
operator.

This leads me to believe operator="State Transit" correct. But reading
on https://www.transport.nsw.gov.au/state-transit/about-us I can learn
that they are an organisation of 3,500 people with approximately 2,900
bus operators. Which leaves me again puzzled and unsure.

So the tags I currently thing are correct are

    operator=Transport for NSW

    network=Sydney Buses

but I'm sure there are others that can shed a better light onto this and
maybe provide some guidance.


Cheers,

Sebastian





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

[OSM-talk-fr] MapContrib [ était GoGoCarto --- demande d'information]

[Vincent Bergeot]

Le 04/07/2020 à 10:18, Yves P. a écrit :


sans doute qu'il faudrait que ces outils de contributions soient plus 
efficients pour contribuer à plusieurs bases en simultanées en 
fonction des contraintes, spécificités de chaque base, …


Faire des formulaires de saisie simples pour mettre des données dans 
OSM n'est pas toujours trivial.


oui bien sur, c'est ce que nous tentons avec mapcontrib, il "suffit" de 
connaître OSM pour mettre en oeuvre des thème comme celui ci (qui m'a 
pris 2')


https://www.mapcontrib.xyz/t/9412be-Les_points_deau_potable#

il est à améliorer avec d'autres tags concernant l'eau, je n'ai pris que 
amenity=drinking_water mais faire des choses ciblées est possible.


nous avions commencé à travailler sur le fait de lier des données non 
osm avec mapcontrib, donc en fait d'alimenter une autre base, mais peu 
utilisé, mis en avant, explqiué


et puis envie de refonte en V2 mais manque de bras (les miens n'étant 
pas bien utile !!! pour coder).





Dans le cas de Owater : Tous les points d'eau 
 on 
peut facilement faire une moissonneuse pour signaler une mise à jour à 
faire dans OSM.
Ça peut être un analyseur pour osmose ou un outil de bureau juste pour 
Stuart…


osmose oui (dans sa version OD, qui fait partie d'une liste au père noël 
), le bureau de stuart non car busfactor :)


dans la V2 de mapcontrib, une des envies était "je récupère un item 
osmose-opendata dans un thème mapcontrib, cela permet de ne pas se 
perdre, de bénéficier de "l'ergonome de mapcontrib" et de la puissance 
d'osmose OD !!! mais V2, bras, temps, disponibilité !!!


à plus

--
Vincent Bergeot

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

Re: [Talk-GB] UPRN Locations Map

[Jez Nicholson]

>From Wikidata, https://m.wikidata.org/wiki/Property:P8399 if you query the
UK Flood service with the UPRN you can see more detail on the property

On Sat, 4 Jul 2020, 08:52 Stephen Colebourne,  wrote:

> I'm not convinced this data should be pulled into OSM. It would add a lot
> of clutter that users would be tempted to move around or delete. In areas
> like mine where I've added thousands of buildings and addresses from
> surveys, it would be making matters worse not better. It would be a
> disincentive to adding more buildings with addresses as the additional
> nodes would get in the way of editing, and because they represent a semi
> random set of things. Because the dataset is fixed I would think it should
> be a layer used alongside OSM by those tools that think it adds value.
> Ideally, OSM itself should support layers, but AFAIK it doesn't.
> Stephen
> PS. Thanks for the slippy map!
>
> On Thu, 2 Jul 2020, 17:38 Robert Whittaker (OSM lists), <
> robert.whittaker+...@gmail.com> wrote:
>
>> I'm not completely sure if/how we can best make use of the new OS
>> OpenData (UPRNs, USRNs and related links) in OpenStreetMap, but as a
>> first step I've set up a quick slippy map with the UPRN locations
>> shown:
>>
>> https://osm.mathmos.net/addresses/uprn/ (zoom in to level 16 to show the
>> data)
>>
>> The UPRN dataset literally just contains the UPRN number and its
>> coordinates (both OS National Grid and WGS lat/lon). There are some
>> additional linking datasets that link these ids to other ids (e.g.
>> USRNs, TOIDs). But no address information is available directly. (You
>> may be able to get street names by matching to OS Open Roads via TOIDs
>> though. Coupled with Code-Point Open, you might be able to assign
>> quite a few postcodes in cases where there's only one unit for a whole
>> street.)
>>
>> The UPRN data has already helped me find a mapping error I made
>> locally though -- it looks like I'd accidentally missed drawing a
>> house outline from aerial imagery, and also classified a large garage
>> a few doors down as a house. The two errors cancelled out when the
>> houses were numbered sequentially, so I didn't notice until now. Today
>> though I spotted a UPRN marker over some blank space on the map, and
>> no marker over the mapped house that's probably a garage.
>>
>> Now a few initial thoughts on the data that I've explored so far:
>>
>> I believe that the UPRNs are assigned by local authorities, so
>> conventions may vary from place to place. I don't know who actually
>> assigns the coordinates (authority or OS). Looking at those for rows
>> of houses around me, they don't seem to have been automatically given
>> coordinates from the house footprint, it looks more like someone
>> manually clicking on a map.
>>
>> The UPRN dataset should include all addressable properties. It is also
>> ahead of reality in some places, as it includes locations for houses
>> on a new development near me that have yet to be built yet. For blocks
>> of apartments/flats, the UPRN nodes may all have the same coordinates
>> or may be displaced from each other, possibly in an artificial manner.
>>
>> Other objects also appear to have UPRNs. Likely things I've noticed so
>> far include: car parks, post boxes, telephone boxes (even after
>> they've been removed), electricity sub-stations, roads and recorded
>> footpaths (the UPRN locations seem to be at one end of the street, so
>> usually lie at a junction), recreation grounds / play areas,
>> floodlight poles (around sports pitches), and allotments. There's no
>> information about the object type in the UPRN data unfortunately.
>>
>> Anyway, I hope some of this is useful / interesting. I hope to be on
>> the OSMUK call on Saturday to discuss things further. Best wishes,
>>
>> Robert.
>>
>> --
>> Robert Whittaker
>> https://osm.mathmos.net/
>>
>> ___
>> 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] Qu'est-ce que le Local Chapters and Communities Working Group (LCCWG) ?

[Yves P.]

> osm-france est un local chapter depuis plus de 2 ans : 
> https://www.openstreetmap.fr/la-fondation-nous-accueille-comme-chapitre-local/
>  
> 
> 
Merci pour l'article :)

__
Yves

PS: la traduction "chapitre local" porte à confusion : On pourrait traduire ça 
par OSM France, représentant local de la Fondation OSM ?

New Oxford American Dictionary
a local chapter of the American Cancer Society: branch, division, subdivision, 
section, department, bureau, agency, lodge, wing, arm, offshoot, subsidiary, 
satellite.

Oxford Thesaurus of English
chiefly North American a local branch of a society: a leaflet was issued by the 
local chapter of the American Cancer Society. 
• a local group of Hell's Angels.

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

Re: [OSM-talk-fr] GoGoCarto --- demande d'information

[European Water Project]

Merci pour ton analyse


 ils arrivent à mobiliser des "communautés" non geek pour contribuer à
des cartes collaboratives,

C’est exactement la raison que leurs contributions ont une telle
potentielle ... s’il y’avait un moyen de faire en sort que leurs
contributions soient sauvegardées dans  osm même quand une carte GoGoCarto
est effacée due à une manque d’activité..

À bientôt,

Stuart






On Sat 4 Jul 2020 at 10:05, Vincent Bergeot  wrote:

> Le 04/07/2020 à 08:57, European Water Project a écrit :
>
> Bonjour Vincent,
>
> Est-ce que ça pourrait être judicieux pour un ou plusieurs développeurs de
> GoGoCarto de s’inscrire sur cette liste : talk-fr ?
>
> si ils en ont envie mais à mon avis c'est un coup à les perdre !
>
> @sebastian est au courant de l'existence de cette liste, quand il y a une
> info qui tourne autour de gogocarto, je lui fais le lien comme hier, donc 1
> fois par trimestre ce qui a mon avis est plus "efficace" que de recevoir
> 200 mais par mois pour savoir si peut-être il y en a 1 qui m'intéresse !
> (et je lui ai demandé si il voulait faire le relais ou que je le fasse).
>
>
> Dans l’article du 22 juin que j’ai envoyé dans un mail précédent ,
> l’auteur parle de la suppression de 550 cartes GoGoCarto sur 800 par faute
> de participation.  Est-ce qu’ils se trompent de modèle pour la pérennité
> des cartes en créant autant de communautés et pas une seule ?
>
> je ne pense pas qu'ils s'adressent à une communauté, mais bien à
> plusieurs. Je ne me permettrais pas de dire qu'ils se trompent de modèle
> car cela voudrait dire que je sais quel modèle choisir (sachant que par
> défaut ils proposent de l'odbl comme licence, ils développent un logiciel
> libre, l'interface et l'usage sont plutôt sympas, ils arrivent à mobiliser
> des "communautés" non geek pour contribuer à des cartes collaboratives, et
> ils sont ouverts à la question des interactions entre ce qu'ils font et OSM
> -> quand j'interpelle mrflos sur l'article dont tu parles (
> https://mstdn.fr/web/statuses/104411039806678070) il embraye direct et
> ajoute (https://mstdn.fr/web/statuses/104411120146531056) plusieurs liens
> vers d'autres projets "voisins".
>
>
> Que penses-tu ?
>
>
> que je suis un promoteur d'osm mais que je vois les limites encore pour
> faire contribuer tout un chacun à cette magnifique base, qu'il y a
> néanmoins pleins de projets fantastiques, que penser des passerelles est
> super intéressant (exemple du boulot de transiscope
> https://transiscope.org/les-technologies-utilisees/ sur le bus
> sémantique, qui récupère via overpass les données osm par exemple), que des
> outils de contributions thématiques à la "mapcontrib" sont sans doute aussi
> des solutions pour agréger des communautés de *contributeurs* mais pas
> encore assez facile à utiliser, sans doute qu'il faudrait que ces outils de
> contributions soient plus efficients pour contribuer à plusieurs bases en
> simultanées en fonction des contraintes, spécificités de chaque base, ...
>
> ceci est une pensée en vrac :)
>
>
>
>
> À bientôt,
>
> Stuart
>
>
>
> On Fri 3 Jul 2020 at 18:12, Vincent Bergeot  wrote:
>
>> Le 03/07/2020 à 18:06, European Water Project a écrit :
>>
>> Bonjour Vincent,
>>
>> Tous les points d'eau que j'ai vu pour l'instant avec  OWATER
>> 
>>  sont d'OSM. Il me semble que la partie : (@43.311,6.470,11z) de l'url
>> est juste pour le display du centre de la carte et le niveau du zoom.
>>
>> confirmation par le développeur je cite "l'url n'a rien à voir, c'est
>> juste que j'ai copié le format google car je trouvais ça plutôt lisible. Et
>> les points sont geolocalisé avec nominatim pas avec google"
>>
>> et en plus "au passage tu peux leur dire pour la license que chaque
>> projet configure sa license, et que de base c'est ODBL"
>>
>>
>> Je partage ton opinion que les gens derrière ce projet auront la volonté
>> de respecter les licences et s'il y a une incompatibilité ils la
>> rectifieront.
>>
>> Ma question était plutôt pour voir s'il y avait moyen d'assurer que les
>> contributions des points d'eau potable de la part des utilisateurs de
>> GoGoCarto et le monde Zero Waste France soient mises directement dans la
>> base de données d'OSM pour que tout le monde en profite.
>>
>> cela serait parfait oui de contribuer une fois pour alimenter plusieurs
>> cartes :)
>>
>>
>>
>>
>>
>>
>> Bien cordialement,
>>
>> Stuart
>>
>>
>>
>> On Fri, 3 Jul 2020 at 17:50, Vincent Bergeot  wrote:
>>
>>> Le 03/07/2020 à 17:40, osm.sanspourr...@spamgourmet.com a écrit :
>>>
>>> Vu le format de l'URL (@43.311,6.470,11z) à la GM j'ai bien peur que les
>>> points n'aient été géolocalisés avec une licence incompatible.
>>>
>>> Ceci dit dans ce cas ils violeraient la licence en question (qui impose
>>> d'afficher sur un fond GM).
>>>
>>> Stuart, je crois que tu es tout désigné comme personne pour leur
>>> conseiller de saisir proprement les données dans un écosystème ODbL.

Re: [talk-ph] Rollback of admin boundary edits in the Philippines due to incompatible license (was Re: Alaminos Barangay borders)

[maning sambale]

FYI, we are starting the rollback, I advise that we don't touch any of
the related changesets until the rollback is done.
https://github.com/OSMPH/papercut_fix/issues/67#issuecomment-653737739

On Tue, Jun 30, 2020 at 3:18 PM maning sambale
 wrote:
>
> Hi Everyone,
>
> After reviewing the edits and communicating with the mapper, we
> decided to roll-back all edits related to this issue due to
> incompatible source.
> We plan to do this as a local community.  Please see the plane here
> for comments and suggestions:
> https://github.com/OSMPH/papercut_fix/issues/67
>
> cc'ed here is OpenStreetMap Foundation's Data Working Group for guidance.
>
> On Fri, Jun 26, 2020 at 4:39 PM Erwin Olario  wrote:
> >
> >
> > Glen, thank you for the heads up! Boundaries are great to have, but I'll 
> > also look into the affected changesets, and reach out to the contributor
> >
> > Are you still in Pangasinan? Stay healthy and safe.
> >
> > /erwin
> >
> > - - - - - - - - - - - - - - - - - - -
> > » email: er...@ngnuity.xyz | gov...@gmail.com
> > » mobile: https://t.me/GOwin
> > » OpenPGP key: 3A93D56B | 5D42 7CCB 8827 9046 1ACB 0B94 63A4 81CE 3A93 D56B
> >
> >
> > On Fri, Jun 26, 2020 at 2:21 PM Glen Scott  wrote:
> >>
> >> Hi PH mapping folks,
> >> I was just in a boring online meeting and had a chance to look at OSM 
> >> (been too busy to get to it for a while).  I noticed Barangay borders have 
> >> been added to Alaminos (and between Alaminos and other Pangasinan cities), 
> >> yet these are radically different to either Alaminos Town Hall maps or the 
> >> Cadastal survey map set I got from DENR.
> >>
> >> The borders were added by VMPanes, I'll try to contact VMPanes to 
> >> establish the basis of the borders. I think that no borders is better than 
> >> incorrect borders, unfortunately I haven't had the time to stitch the 
> >> cadastral set together in electronic format to arrive at a more accurate 
> >> border than the Alaminos City Hall map, which is at quite a small scale.
> >>
> >> Cheers
> >> Glen
> >>
> >>
> >> ___
> >> talk-ph mailing list
> >> talk-ph@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-ph
> >
> > ___
> > talk-ph mailing list
> > talk-ph@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ph
>
>
>
> --
> cheers,
> maning
> --
> "Freedom is still the most radical idea of all" -N.Branden
> https://github.com/maning
> http://twitter.com/maningsambale
> --
>
> ___
> talk-ph mailing list
> talk-ph@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ph



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
https://github.com/maning
http://twitter.com/maningsambale
--

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

Re: [OSM-talk-fr] GoGoCarto --- demande d'information

[Yves P.]

> sans doute qu'il faudrait que ces outils de contributions soient plus 
> efficients pour contribuer à plusieurs bases en simultanées en fonction des 
> contraintes, spécificités de chaque base, …
> 
Faire des formulaires de saisie simples pour mettre des données dans OSM n'est 
pas toujours trivial.

Dans le cas de Owater : Tous les points d'eau 
 on 
peut facilement faire une moissonneuse pour signaler une mise à jour à faire 
dans OSM.
Ça peut être un analyseur pour osmose ou un outil de bureau juste pour Stuart…
> ceci est une pensée en vrac :)
> 
itou

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

Re: [OSM-talk-fr] Qu'est-ce que le Local Chapters and Communities Working Group (LCCWG) ?

[Vincent Bergeot]

Le 04/07/2020 à 07:59, Yves P. a écrit :

Bonjour,

Ce soir à 23h30 au SOTM, Maggie Cawley d'OpenStreetMap US présente 
Building Stronger Communities Together - the Local Chapters & 
Community Working Group .


En lisant la page du wiki de la fondation OSM Local Chapters and 
Communities Working Group 
, 
il me semble qu'il n'y a aucun membre francophone.


Un local chapter (= une branche locale d'une association) est-il à 
l'échelle d'un pays (par exemple OSM France) ou est-ce que ça désigne 
un groupe local comme Digne-les-Bains ?


osm-france est un local chapter depuis plus de 2 ans : 
https://www.openstreetmap.fr/la-fondation-nous-accueille-comme-chapitre-local/



Est-ce que Emilie Laffray et Christian Quest en qualité d'anciens 
membres, peuvent nous en dire plus ?



à plus

--
Vincent Bergeot

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

Re: [OSM-talk-fr] GoGoCarto --- demande d'information

[Vincent Bergeot]

Le 04/07/2020 à 08:57, European Water Project a écrit :

Bonjour Vincent,

Est-ce que ça pourrait être judicieux pour un ou plusieurs 
développeurs de GoGoCarto de s’inscrire sur cette liste : talk-fr ?


si ils en ont envie mais à mon avis c'est un coup à les perdre !

@sebastian est au courant de l'existence de cette liste, quand il y a 
une info qui tourne autour de gogocarto, je lui fais le lien comme hier, 
donc 1 fois par trimestre ce qui a mon avis est plus "efficace" que de 
recevoir 200 mais par mois pour savoir si peut-être il y en a 1 qui 
m'intéresse ! (et je lui ai demandé si il voulait faire le relais ou que 
je le fasse).




Dans l’article du 22 juin que j’ai envoyé dans un mail précédent , 
l’auteur parle de la suppression de 550 cartes GoGoCarto sur 800 par 
faute de participation.  Est-ce qu’ils se trompent de modèle pour la 
pérennité des cartes en créant autant de communautés et pas une seule ?


je ne pense pas qu'ils s'adressent à une communauté, mais bien à 
plusieurs. Je ne me permettrais pas de dire qu'ils se trompent de modèle 
car cela voudrait dire que je sais quel modèle choisir (sachant que par 
défaut ils proposent de l'odbl comme licence, ils développent un 
logiciel libre, l'interface et l'usage sont plutôt sympas, ils arrivent 
à mobiliser des "communautés" non geek pour contribuer à des cartes 
collaboratives, et ils sont ouverts à la question des interactions entre 
ce qu'ils font et OSM -> quand j'interpelle mrflos sur l'article dont tu 
parles (https://mstdn.fr/web/statuses/104411039806678070) il embraye 
direct et ajoute (https://mstdn.fr/web/statuses/104411120146531056) 
plusieurs liens vers d'autres projets "voisins".




Que penses-tu ?



que je suis un promoteur d'osm mais que je vois les limites encore pour 
faire contribuer tout un chacun à cette magnifique base, qu'il y a 
néanmoins pleins de projets fantastiques, que penser des passerelles est 
super intéressant (exemple du boulot de transiscope 
https://transiscope.org/les-technologies-utilisees/ sur le bus 
sémantique, qui récupère via overpass les données osm par exemple), que 
des outils de contributions thématiques à la "mapcontrib" sont sans 
doute aussi des solutions pour agréger des communautés de 
*contributeurs* mais pas encore assez facile à utiliser, sans doute 
qu'il faudrait que ces outils de contributions soient plus efficients 
pour contribuer à plusieurs bases en simultanées en fonction des 
contraintes, spécificités de chaque base, ...


ceci est une pensée en vrac :)





À bientôt,

Stuart



On Fri 3 Jul 2020 at 18:12, Vincent Bergeot > wrote:


Le 03/07/2020 à 18:06, European Water Project a écrit :

Bonjour Vincent,

Tous les points d'eau que j'ai vu pour l'instant avec OWATER

sont d'OSM. Il me semble que la partie : (@43.311,6.470,11z) de
l'url est juste pour le display du centre de la carte et le
niveau du zoom.


confirmation par le développeur je cite "l'url n'a rien à voir,
c'est juste que j'ai copié le format google car je trouvais ça
plutôt lisible. Et les points sont geolocalisé avec nominatim pas
avec google"

et en plus "au passage tu peux leur dire pour la license que
chaque projet configure sa license, et que de base c'est ODBL"



Je partage ton opinion que les gens derrière ce projet auront la
volonté de respecter les licences et s'il y a une incompatibilité
ils la rectifieront.

Ma question était plutôt pour voir s'il y avait moyen d'assurer
que les contributions des points d'eau potable de la part des
utilisateurs de GoGoCarto et le monde Zero Waste France soient
mises directement dans la base de données d'OSM pour que tout le
monde en profite.


cela serait parfait oui de contribuer une fois pour alimenter
plusieurs cartes :)







Bien cordialement,

Stuart



On Fri, 3 Jul 2020 at 17:50, Vincent Bergeot mailto:vinc...@bergeot.org>> wrote:

Le 03/07/2020 à 17:40, osm.sanspourr...@spamgourmet.com
 a écrit :


Vu le format de l'URL (@43.311,6.470,11z) à la GM j'ai bien
peur que les points n'aient été géolocalisés avec une
licence incompatible.

Ceci dit dans ce cas ils violeraient la licence en question
(qui impose d'afficher sur un fond GM).

Stuart, je crois que tu es tout désigné comme personne pour
leur conseiller de saisir proprement les données dans un
écosystème ODbL.

Oui on pense au même^^.



Bonjour,

il y a eu des échanges avec d'une part le dev de gogocarto
qui est venu à mon invitation en 2018 au sotm-fr présenté la
carte Près de chez nous, qui a initié le projet gogocarto. Le
canal de discussion est ici :
https://chat.lescommuns.org/channel/gogocarto

D'autre part, 

Re: [Talk-GB] UPRN Locations Map

[Stephen Colebourne]

I'm not convinced this data should be pulled into OSM. It would add a lot
of clutter that users would be tempted to move around or delete. In areas
like mine where I've added thousands of buildings and addresses from
surveys, it would be making matters worse not better. It would be a
disincentive to adding more buildings with addresses as the additional
nodes would get in the way of editing, and because they represent a semi
random set of things. Because the dataset is fixed I would think it should
be a layer used alongside OSM by those tools that think it adds value.
Ideally, OSM itself should support layers, but AFAIK it doesn't.
Stephen
PS. Thanks for the slippy map!

On Thu, 2 Jul 2020, 17:38 Robert Whittaker (OSM lists), <
robert.whittaker+...@gmail.com> wrote:

> I'm not completely sure if/how we can best make use of the new OS
> OpenData (UPRNs, USRNs and related links) in OpenStreetMap, but as a
> first step I've set up a quick slippy map with the UPRN locations
> shown:
>
> https://osm.mathmos.net/addresses/uprn/ (zoom in to level 16 to show the
> data)
>
> The UPRN dataset literally just contains the UPRN number and its
> coordinates (both OS National Grid and WGS lat/lon). There are some
> additional linking datasets that link these ids to other ids (e.g.
> USRNs, TOIDs). But no address information is available directly. (You
> may be able to get street names by matching to OS Open Roads via TOIDs
> though. Coupled with Code-Point Open, you might be able to assign
> quite a few postcodes in cases where there's only one unit for a whole
> street.)
>
> The UPRN data has already helped me find a mapping error I made
> locally though -- it looks like I'd accidentally missed drawing a
> house outline from aerial imagery, and also classified a large garage
> a few doors down as a house. The two errors cancelled out when the
> houses were numbered sequentially, so I didn't notice until now. Today
> though I spotted a UPRN marker over some blank space on the map, and
> no marker over the mapped house that's probably a garage.
>
> Now a few initial thoughts on the data that I've explored so far:
>
> I believe that the UPRNs are assigned by local authorities, so
> conventions may vary from place to place. I don't know who actually
> assigns the coordinates (authority or OS). Looking at those for rows
> of houses around me, they don't seem to have been automatically given
> coordinates from the house footprint, it looks more like someone
> manually clicking on a map.
>
> The UPRN dataset should include all addressable properties. It is also
> ahead of reality in some places, as it includes locations for houses
> on a new development near me that have yet to be built yet. For blocks
> of apartments/flats, the UPRN nodes may all have the same coordinates
> or may be displaced from each other, possibly in an artificial manner.
>
> Other objects also appear to have UPRNs. Likely things I've noticed so
> far include: car parks, post boxes, telephone boxes (even after
> they've been removed), electricity sub-stations, roads and recorded
> footpaths (the UPRN locations seem to be at one end of the street, so
> usually lie at a junction), recreation grounds / play areas,
> floodlight poles (around sports pitches), and allotments. There's no
> information about the object type in the UPRN data unfortunately.
>
> Anyway, I hope some of this is useful / interesting. I hope to be on
> the OSMUK call on Saturday to discuss things further. Best wishes,
>
> Robert.
>
> --
> Robert Whittaker
> https://osm.mathmos.net/
>
> ___
> 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] Tag pour les services d'un établissement, quand ils sont adaptés aux fauteuils roulants

[Yves P.]

>> C'est pour cela qu'il faut utiliser *:description=* pour le préciser pour 
>> nos "amis"
> Ben pour moi wheelchair:description c'est détailler l'accessibilité du lieu, 
> vu que wheelchair c'est sur le lieu en lui même.

Ce que j'essaie d'expliquer c'est que de toute façon ça va être difficile de 
faire rentrer chaque handicap dans un tag, et que pour être vraiment utile, il 
faut compléter avec un tag description.

On pourrait avoir quelque chose comme wheelchair=yes + 
wheelchair:description="activité parapente accessible pour les personnes avec 
tonicité et sans respirateur"

J'ai trouvé un exemple réel : 6 plages vers Narbonnes avec wheelchair=yes + 
wheelchair:description="Fauteuil Tiralo disponible au poste de secours"
https://overpass-turbo.eu/s/VMu 

Pour avoir l'expérience d'un système similaire au tiralo , 
il peut-être aussi utilisé par des personnes ayant plutôt des handicaps mentaux 
ou neurologiques mais qui marche.
Comment décrire ça avec des tags avec des valeurs yes/no ?

Avoir le dispositif adapté c'est bien (tiralo  pour la 
baignade, tandemflex  pour le ski, une 
escargoline  
pour le la rando pédestre ou avec un âne…)…
Avoir le sytème de "transfert" c'est mieux ;)
"transfert pour passer du fauteuil de la personne au dispositif adapté pour 
faire du sport.

Je me répète, comment décrire ça avec de "simples" tags ?

>> Ou alors se mettre d'accord sur un Nième tag *:for=*
> :for pour moi c'est sur la cible du lieu. Le club de parapente est open et 
> adapté et ne développe pas un service exclusivement pour les personnes 
> handicapées. Si je regarde le wiki sur social_facility:for, ça dit :
> 
Pour moi aussi, mais avoir trop de tags dilue l'info, rends les outils de 
saisie, d'analyse et de recherche plus compliqué à écrire et à maintenir.

J'ai fait une rapide recherche dans taginfo :
disabled:description 
=* (1 seul 
tag)
mental_disabled:description:fr 
=*
 (49 tags avec 6 valeurs différentes qui me paraissent curieuses ou peu utiles)
wheelchair:description 
=*
wheelchair:description:cs 
=*
wheelchair:description:de 
=*


Exemple d'un école Relation 1461377 

• access:blind=limited
• access:deaf=yes
• access:mental_disabled=yes
• wheelchair=limited
• toilets:wheelchair=no
• blind:description:fr=Accès possible aux aveugles et aux malvoyants au 
niveau RDC. Présence de marches et absence de mains courantes sur le 
cheminement. Étage inaccessible.
• deaf:description:fr=Accessible aux sourds et malentendants. Entrée 
non conforme, absence de dispositif adapté.
• mental_disabled:description:fr=Accessible aux handicapés mentaux. 
Entrée non conforme, absence de dispositif adapté.
• walking_disability:description:fr=Accès difficile aux fauteuils 
roulants et aux PMR au niveau RDC. Présence de marches sur le cheminement 
principal. Absence de mains courantes. Étage inaccessible.

Que veut dire "Entrée non conforme, absence de dispositif adapté." pour les 
handicaps auditifs et mentaux ??

Quelle application gère les 150~ tags walking_disability 
, 
walking_disability:description 
 et 
walking_disability:description:fr 
 ?

>> Sachant qu'il n'y a pas un handicap, mais plusieurs grandes catégories et du 
>> cas par cas ensuite…
> yes, des fois ça peut être ok d'utiliser disabled, des fois il vaudra mieux 
> spécifier wheelchair/blind…
> 
Je prends un exemple "simple" : la place de stationnement.
Que veux dire wheelchair=yes ou même wheelchair=designated ?

Qu'il y a un rectangle bleu peint au sol avec un logo blanc représentant un 
fauteuil roulant et un panneau similaire devant ;D

Sérieusement, qu'est-ce que ça veut dire pour vous ?

__
Yves


—
Yves Pratter




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

Re: [OSM-talk-fr] GoGoCarto --- demande d'information

[European Water Project]

Bonjour Vincent,

Est-ce que ça pourrait être judicieux pour un ou plusieurs développeurs de
GoGoCarto de s’inscrire sur cette liste : talk-fr ?

Dans l’article du 22 juin que j’ai envoyé dans un mail précédent , l’auteur
parle de la suppression de 550 cartes GoGoCarto sur 800 par faute de
participation.  Est-ce qu’ils se trompent de modèle pour la pérennité des
cartes en créant autant de communautés et pas une seule ?

Que penses-tu ?

À bientôt,

Stuart



On Fri 3 Jul 2020 at 18:12, Vincent Bergeot  wrote:

> Le 03/07/2020 à 18:06, European Water Project a écrit :
>
> Bonjour Vincent,
>
> Tous les points d'eau que j'ai vu pour l'instant avec  OWATER
> 
>  sont d'OSM. Il me semble que la partie : (@43.311,6.470,11z) de l'url
> est juste pour le display du centre de la carte et le niveau du zoom.
>
> confirmation par le développeur je cite "l'url n'a rien à voir, c'est
> juste que j'ai copié le format google car je trouvais ça plutôt lisible. Et
> les points sont geolocalisé avec nominatim pas avec google"
>
> et en plus "au passage tu peux leur dire pour la license que chaque projet
> configure sa license, et que de base c'est ODBL"
>
>
> Je partage ton opinion que les gens derrière ce projet auront la volonté
> de respecter les licences et s'il y a une incompatibilité ils la
> rectifieront.
>
> Ma question était plutôt pour voir s'il y avait moyen d'assurer que les
> contributions des points d'eau potable de la part des utilisateurs de
> GoGoCarto et le monde Zero Waste France soient mises directement dans la
> base de données d'OSM pour que tout le monde en profite.
>
> cela serait parfait oui de contribuer une fois pour alimenter plusieurs
> cartes :)
>
>
>
>
>
>
> Bien cordialement,
>
> Stuart
>
>
>
> On Fri, 3 Jul 2020 at 17:50, Vincent Bergeot  wrote:
>
>> Le 03/07/2020 à 17:40, osm.sanspourr...@spamgourmet.com a écrit :
>>
>> Vu le format de l'URL (@43.311,6.470,11z) à la GM j'ai bien peur que les
>> points n'aient été géolocalisés avec une licence incompatible.
>>
>> Ceci dit dans ce cas ils violeraient la licence en question (qui impose
>> d'afficher sur un fond GM).
>>
>> Stuart, je crois que tu es tout désigné comme personne pour leur
>> conseiller de saisir proprement les données dans un écosystème ODbL.
>>
>> Oui on pense au même^^.
>>
>>
>> Bonjour,
>>
>> il y a eu des échanges avec d'une part le dev de gogocarto qui est venu à
>> mon invitation en 2018 au sotm-fr présenté la carte Près de chez nous, qui
>> a initié le projet gogocarto. Le canal de discussion est ici :
>> https://chat.lescommuns.org/channel/gogocarto
>>
>> D'autre part, je suis en discussion avec des gens de transiscope qui
>> utilise Gogogocarto, avec aussi Christian de Nantes qui travaille sur les
>> projets cartovrac et autres dans OSM. En particulier pour arriver à faire
>> des ponts entre transiscope (https://transiscope.org/) et OSM.
>>
>> Que cela soit le dev de gogocarto ou les gens de transiscope, ils sont
>> attentifs à la question des licences avec l'envie d'avancer sur les ponts
>> entre les projets.
>>
>> PS : Je ne pense pas que l'url soit représentative de la manière dont le
>> géocodage a été fait, des points sont ajoutés à la main, avec tout un
>> système de validation. Je me renseigne :)
>>
>>
>> Jean-Yvon
>> Le 03/07/2020 à 16:29, Yves P. - yves.prat...@gmail.com a écrit :
>>
>>
>> Mais en cherchant où se trouve la doc
>> ,
>> on fini par voir qu'il est possible d'importer et d'exporter des données
>> (licence ??)
>>
>> Comme dans umap -> Tu peux récupérer les données, mais si aucune licence
>> n'est posée sur les données tu ne peux pas t'en servir !
>>
>> --
>> Vincent Bergeot
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
> --
> Vincent Bergeot
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Qu'est-ce que le Local Chapters and Communities Working Group (LCCWG) ?

[Yves P.]

Bonjour,

Ce soir à 23h30 au SOTM, Maggie Cawley d'OpenStreetMap US présente Building 
Stronger Communities Together - the Local Chapters & Community Working Group 
.

En lisant la page du wiki de la fondation OSM Local Chapters and Communities 
Working Group 
,
 il me semble qu'il n'y a aucun membre francophone.

Un local chapter (= une branche locale d'une association) est-il à l'échelle 
d'un pays (par exemple OSM France) ou est-ce que ça désigne un groupe local 
comme Digne-les-Bains ?

Est-ce que Emilie Laffray et Christian Quest en qualité d'anciens membres, 
peuvent nous en dire plus ?


__
Yves

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