Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[Andrew Hain]

The wiki has definitely had problems recently and we should have a good 
discussion about what we want from it.

--
Andrew

From: Paul Johnson 
Sent: 10 August 2018 18:13:36
To: Tomasz Wójcik
Cc: Talk Openstreetmap
Subject: Re: [OSM-talk] highway=* + area=yes vs area:highway=*

Sounds fine by me.  Seems there's a decent sized contingency working the wiki 
independently of how things are actually tagged anymore, it's been getting hard 
to point to the wiki as a usable reference for a couple years now.

On Fri, Aug 10, 2018, 05:08 Tomasz Wójcik mailto:tom...@wp.pl>> 
wrote:
So basing on your opinions, it looks like highway=* + area=yes isn't
incorrect, it's just not documented. What do you guys think about adding
a better documentation of combination with area=yes to some of highway=*
Wiki pages?


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Oleksiy Muzalyev]

On 11.08.18 00:58, Andrew Harvey wrote:


I agree, unless people start putting up signs of the Plus Codes 
outside their house and you're mapping that as the on the ground 
housenumber. ...



___


And they will not start putting up signs of the Plus-Codes outside their 
house unless the OpenStreetMap community accept this technology. This 
was a minor experimental import for a small remote town Zeze in the 
United Republic of Tanzania. Nothing happened. It is not an issue. Zeze 
is well mapped at OpenStreetMap, but it is not present at the Google Maps.


If the OSM community accepts the OpenLocationCode, then it would become 
de facto universal addressing system. Only then people may start 
believing and investing in it.


Best regards,

Oleksiy


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Martin Trautmann]

On 18-08-09 15:32, oleksiy.muzal...@bluewin.ch wrote:
> Open Location Codes are also referred to as "plus codes".  Since August
> 2015, Google Maps supports plus codes in their search engine. The
> algorithm is Open Source, licensed under the Apache License 2.0. and
> available on GitHub [1].

Please let me help to understand OLC: is this nothing else than another
representation of lat and lon?

This may be good enough for rural areas and small buildings. But I do
not understand how it should work for very tall buildings.

How would you proceed for those tall buildings?

So how do you provide your OLC? It's the OLC of your actual location?
And you do add the OLC for the entry to your tall building?
(where bells or letter boxes might be located? Or is this an extra OLC?)
And as an extra you do provide the entry to your street?

And this is still a two dimensional address only? How about multilevel
buildings?

I do thing especially about tall buildings with a maze of corridors.
You'd need a list of OLC waypoints how to find your location - within a
building, where GPS will not work.

- Martin



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

Re: [Talk-de] Datum einer Kontrolle vermerken?

[Markus]

Hallo Andreas,

> häufig sind vorhandene Tags veraltet und falsch. 
> sinnvoll: Zeitstempel der letzen Überprüfung
> Damit könnte ich mir alle Objekte herausfiltern, die z.B.
> länger als ein Jahr nicht überprüft wurden und gezielt hinfahren.

:-)

Das macht man in jedem Standard-Dokumenten-Management so.
Im Qualitätsmanagement sowieso.
Im Alltag gibt es das Ablaufdatum für jedes Lebensmittel
und jedes Fahrzeug muss regelmässig zum "TÜV" oder so.

In OSM gibt es:

survey:date = [-mm-tt]
Datum der *letzten persönlichen Prüfung vor Ort*
Derzeit ~482' mal in Gebrauch.
https://wiki.openstreetmap.org/wiki/Key:survey:date
(leider noch nicht in deutsch)

check_date = [-mm-tt]
+ source = *
Datum der *letzten offiziellen Quelle* nach der das Objekt zum letzten
Mal geprüft wurde.
Macht natürlich nur Sinn, wenn man auch die verwendete Quelle als
filterbares tag angibt.
Derzeit ~68'000 mal in Gebrauch.
https://wiki.openstreetmap.org/wiki/Key:check_date

Datumsformat nach ISO-8601: jjj-mm-tt

Und nein: das "bläht" die Datenbank nicht auf.
Sondern das ist ein wesentlicher Qualitätshinweis!
Denn nur eine nachgewiesen aktuelle Datenbank ist eine gute Datenbank :-)

Nach wie vor bleibt aber die Schwierigkeit, dass damit nur eine
*unspezifische Überprüfung* dokumentiert wird.

Denn wenn ich z.B. beobachtet habe, dass der Briefkasten von der
ursprünglichen Strassenecke an die gegenüberliegende umgesetzt wurde,
und ich das eintrage und mit "survey:date" dokumentiere, ist nicht klar,
ob ich "collection_times" ebenfalls überprüft habe? oder einfach davon
ausgegangen bin, dass das immer noch das gleiche sei wie vor x-Jahren ;-)

Mit herzlichem Gruss,
Markus

PS: manche meinen, dass es besser wäre, das alles in das changeset zu
schreiben, aber das ist nur in Prosa und damit nicht filterbar.



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

Re: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org

[Philippe Verdy]

Voir aussi cette page de doc de wget au sujet des "timestamps".

https://www.gnu.org/software/wget/manual/html_node/Time_002dStamping-Usage.html

Et la note concernant FTP:

https://www.gnu.org/software/wget/manual/html_node/FTP-Time_002dStamping-Internals.html#FTP-Time_002dStamping-Internals


Le sam. 11 août 2018 à 05:57, Philippe Verdy  a écrit :

> Une piste à propos de Wget (voir http://www.gnu.org/software/wget/) qui
> indique :
>  "Uses local file timestamps to determine whether documents need to be
> re-downloaded when mirroring"
>
> Note: "wget" peut utiliser HTTP ou FTP, mais les serveurs FTP sont connus
> pour ne pas afficher la date UTC mais uniquement la date locale du serveur
> source : le client FTP ne sait pas quell est la date locale du serveur ! En
> HTTP la précision du fuseau est normalement obligatoire dans les entêtes
> MIME, ce n'est pas le cas de FTP. La note ci-dessus peut indiquer un
> changement pour qu'en HTTP, wget se comporte comme en FTP (et cela suppose
> donc alors que le client positionne d'abord sa date locale avec le fuseau
> horaire du serveur interrogé avant d'utiliser "wget")... Ce serait bien de
> vérifier ça si wget a bien été modifié sur la façon d'interpréter les dates
> indiquées par le serveur distant: le serveur distant étant en HTTP ici, il
> doit préciser ce fuseau, mais l'info est perdue/ignorée en cours de route.
>
>
> Le sam. 11 août 2018 à 05:45, Philippe Verdy  a
> écrit :
>
>> Il toutefois que la synchro des diffs est basée sur les dates rapportées
>> par  https://tile.openstreetmap.org/cgi-bin/debug
>> Il n'est pas clairement précisé dans ce "debug" comment est calculée
>> cette date : est-ce une date "UTC" ou une date locale ? Sachant que les
>> déménagement d'un serveur de Londres à Amsterdam change la date locale d'1
>> heure avec le changement de fuseau horaire. Reste à savoir de quel serveur
>> viennent ces diffs sources: ils étaient générés à Londres sur l'instance
>> principale, qui a été déménagée à Amsterdam.
>>
>> Un des outils d'Ubuntu a pu changer la date affichée par défaut pour
>> passer de l'heure UTC à l'heure locale du serveur...
>> Ce serait donc bien lié au déménagement d'une partie des serveurs. Mais
>> le bogue serait lié à une soucis de compatibilité d'un des utilitaires
>> d'Ubuntu mis à jour.
>>
>> Cela n'explique pas complètement pourquoi "Vial" (qui est resté en
>> Allemagne) n'est pas affecté par le changement de date locale sur le
>> serveur de base de données principal (déménagé de Londres à Amsterdam),
>> mais on doit noter que lui n'a pas encore eu la mise à jour vers Ubuntu
>> 18.04.
>>
>> On doit chercher du côté de l'outil de téléchargement des diffs utilisé
>> sur les serveurs esclaves (probablement "wget"). Ce serait un bogue de
>> compatibilité de cet outil dans la façon de gérer et rapporter les dates
>> (locales ou UTC) : le serveur principal omet de préciser son fuseau horaire
>> (mais si le protocole est HTTP ou HTTPS, normalement ce fuseau horaire est
>> précisé dans les entêtes HTTP), et le script sur le serveur escalve faisant
>> la requête HTTP interprète alors la date de façon différente en Ubuntu
>> 18.04 si le fuseau n'est pas précisé (16.04: supposerait que la date est
>> indiquée en UTC; 18.04 : supposerait que la date est indiquée dans la date
>> locale du serveur local)
>>
>>
>>
>>
>>
>> Le sam. 11 août 2018 à 05:27, Philippe Verdy  a
>> écrit :
>>
>>>
>>> le serveur utilisé actuellement dépend de la position géographique
 principalement mais peux aussi changer en cas de surcharge,
 info vérifiable en temps réel avec
 https://tile.openstreetmap.org/cgi-bin/debug
 les 2 serveurs ok : Yevaud et Vial
 les 2 serveurs affectés : Scorch et Rhaegal

>>>
>>> Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch", et
>>> "orm" (et non pas "rhaegal" ou c'est un ancien alias).
>>> - "Yevaud" est encore à Londres (à l'UCL), mais n'a pas eu la mise à
>>> jour d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue
>>> - "Vial" est en Allemagne (à Hetzner), mais n'a pas eu la mise à jour
>>> d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue
>>> - "Scorch" est en France (à Roubais chez OVH): il est affecté par le
>>> bogue, Ubuntu été mis à jour de 16.04 vers 18.04
>>> - "Orm" était parmi les serveurs déménagés de Londres (à l'UCL) à
>>> Amsterdam (chez Equinix): il est affecté par le bogue, Ubuntu été mis à
>>> jour de 16.04 vers 18.04
>>>
>>> La mise à jour d'Ubuntu n'explique pas le rendu incorrect et la
>>> persistence de ways parasites (marqués comme supprimés dans les "diffs"
>>> mais qui sont tracés avec une partie des noeuds conservés par ailleurs). Il
>>> semble que l'impact de cette mise à jour serait que les fichiers "diffs"
>>> seraient traités alors qu'ils ne sont pas complètement téléchargés : le
>>> traitement se fait sur une partie seulement des changesets qui sont alors
>>> tronqués.
>>>
>>> Ce n'est apparemment pas un problème de base de données 

Re: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org

[Philippe Verdy]

Une piste à propos de Wget (voir http://www.gnu.org/software/wget/) qui
indique :
 "Uses local file timestamps to determine whether documents need to be
re-downloaded when mirroring"

Note: "wget" peut utiliser HTTP ou FTP, mais les serveurs FTP sont connus
pour ne pas afficher la date UTC mais uniquement la date locale du serveur
source : le client FTP ne sait pas quell est la date locale du serveur ! En
HTTP la précision du fuseau est normalement obligatoire dans les entêtes
MIME, ce n'est pas le cas de FTP. La note ci-dessus peut indiquer un
changement pour qu'en HTTP, wget se comporte comme en FTP (et cela suppose
donc alors que le client positionne d'abord sa date locale avec le fuseau
horaire du serveur interrogé avant d'utiliser "wget")... Ce serait bien de
vérifier ça si wget a bien été modifié sur la façon d'interpréter les dates
indiquées par le serveur distant: le serveur distant étant en HTTP ici, il
doit préciser ce fuseau, mais l'info est perdue/ignorée en cours de route.


Le sam. 11 août 2018 à 05:45, Philippe Verdy  a écrit :

> Il toutefois que la synchro des diffs est basée sur les dates rapportées
> par  https://tile.openstreetmap.org/cgi-bin/debug
> Il n'est pas clairement précisé dans ce "debug" comment est calculée cette
> date : est-ce une date "UTC" ou une date locale ? Sachant que les
> déménagement d'un serveur de Londres à Amsterdam change la date locale d'1
> heure avec le changement de fuseau horaire. Reste à savoir de quel serveur
> viennent ces diffs sources: ils étaient générés à Londres sur l'instance
> principale, qui a été déménagée à Amsterdam.
>
> Un des outils d'Ubuntu a pu changer la date affichée par défaut pour
> passer de l'heure UTC à l'heure locale du serveur...
> Ce serait donc bien lié au déménagement d'une partie des serveurs. Mais le
> bogue serait lié à une soucis de compatibilité d'un des utilitaires
> d'Ubuntu mis à jour.
>
> Cela n'explique pas complètement pourquoi "Vial" (qui est resté en
> Allemagne) n'est pas affecté par le changement de date locale sur le
> serveur de base de données principal (déménagé de Londres à Amsterdam),
> mais on doit noter que lui n'a pas encore eu la mise à jour vers Ubuntu
> 18.04.
>
> On doit chercher du côté de l'outil de téléchargement des diffs utilisé
> sur les serveurs esclaves (probablement "wget"). Ce serait un bogue de
> compatibilité de cet outil dans la façon de gérer et rapporter les dates
> (locales ou UTC) : le serveur principal omet de préciser son fuseau horaire
> (mais si le protocole est HTTP ou HTTPS, normalement ce fuseau horaire est
> précisé dans les entêtes HTTP), et le script sur le serveur escalve faisant
> la requête HTTP interprète alors la date de façon différente en Ubuntu
> 18.04 si le fuseau n'est pas précisé (16.04: supposerait que la date est
> indiquée en UTC; 18.04 : supposerait que la date est indiquée dans la date
> locale du serveur local)
>
>
>
>
>
> Le sam. 11 août 2018 à 05:27, Philippe Verdy  a
> écrit :
>
>>
>> le serveur utilisé actuellement dépend de la position géographique
>>> principalement mais peux aussi changer en cas de surcharge,
>>> info vérifiable en temps réel avec
>>> https://tile.openstreetmap.org/cgi-bin/debug
>>> les 2 serveurs ok : Yevaud et Vial
>>> les 2 serveurs affectés : Scorch et Rhaegal
>>>
>>
>> Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch", et
>> "orm" (et non pas "rhaegal" ou c'est un ancien alias).
>> - "Yevaud" est encore à Londres (à l'UCL), mais n'a pas eu la mise à jour
>> d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue
>> - "Vial" est en Allemagne (à Hetzner), mais n'a pas eu la mise à jour
>> d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue
>> - "Scorch" est en France (à Roubais chez OVH): il est affecté par le
>> bogue, Ubuntu été mis à jour de 16.04 vers 18.04
>> - "Orm" était parmi les serveurs déménagés de Londres (à l'UCL) à
>> Amsterdam (chez Equinix): il est affecté par le bogue, Ubuntu été mis à
>> jour de 16.04 vers 18.04
>>
>> La mise à jour d'Ubuntu n'explique pas le rendu incorrect et la
>> persistence de ways parasites (marqués comme supprimés dans les "diffs"
>> mais qui sont tracés avec une partie des noeuds conservés par ailleurs). Il
>> semble que l'impact de cette mise à jour serait que les fichiers "diffs"
>> seraient traités alors qu'ils ne sont pas complètement téléchargés : le
>> traitement se fait sur une partie seulement des changesets qui sont alors
>> tronqués.
>>
>> Ce n'est apparemment pas un problème de base de données (sur la base de
>> données esclave), mais des outils de téléchargement et synchronisation de
>> répertoires (je ne sais pas si cela se fait par "rsync" ou pour un script
>> shell avec "wget", mais cet outil ne semble pas correctement synchronisé
>> avec l'outil qui va ensuite traiter les nouveau diffs reçus et "prêts" pour
>> les charger sur la base esclave, une ancienen opération qui était bloquante
>> semble être devenue asynchrone et il manque une étape 

Re: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org

[Philippe Verdy]

Il toutefois que la synchro des diffs est basée sur les dates rapportées
par  https://tile.openstreetmap.org/cgi-bin/debug
Il n'est pas clairement précisé dans ce "debug" comment est calculée cette
date : est-ce une date "UTC" ou une date locale ? Sachant que les
déménagement d'un serveur de Londres à Amsterdam change la date locale d'1
heure avec le changement de fuseau horaire. Reste à savoir de quel serveur
viennent ces diffs sources: ils étaient générés à Londres sur l'instance
principale, qui a été déménagée à Amsterdam.

Un des outils d'Ubuntu a pu changer la date affichée par défaut pour passer
de l'heure UTC à l'heure locale du serveur...
Ce serait donc bien lié au déménagement d'une partie des serveurs. Mais le
bogue serait lié à une soucis de compatibilité d'un des utilitaires
d'Ubuntu mis à jour.

Cela n'explique pas complètement pourquoi "Vial" (qui est resté en
Allemagne) n'est pas affecté par le changement de date locale sur le
serveur de base de données principal (déménagé de Londres à Amsterdam),
mais on doit noter que lui n'a pas encore eu la mise à jour vers Ubuntu
18.04.

On doit chercher du côté de l'outil de téléchargement des diffs utilisé sur
les serveurs esclaves (probablement "wget"). Ce serait un bogue de
compatibilité de cet outil dans la façon de gérer et rapporter les dates
(locales ou UTC) : le serveur principal omet de préciser son fuseau horaire
(mais si le protocole est HTTP ou HTTPS, normalement ce fuseau horaire est
précisé dans les entêtes HTTP), et le script sur le serveur escalve faisant
la requête HTTP interprète alors la date de façon différente en Ubuntu
18.04 si le fuseau n'est pas précisé (16.04: supposerait que la date est
indiquée en UTC; 18.04 : supposerait que la date est indiquée dans la date
locale du serveur local)





Le sam. 11 août 2018 à 05:27, Philippe Verdy  a écrit :

>
> le serveur utilisé actuellement dépend de la position géographique
>> principalement mais peux aussi changer en cas de surcharge,
>> info vérifiable en temps réel avec
>> https://tile.openstreetmap.org/cgi-bin/debug
>> les 2 serveurs ok : Yevaud et Vial
>> les 2 serveurs affectés : Scorch et Rhaegal
>>
>
> Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch", et
> "orm" (et non pas "rhaegal" ou c'est un ancien alias).
> - "Yevaud" est encore à Londres (à l'UCL), mais n'a pas eu la mise à jour
> d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue
> - "Vial" est en Allemagne (à Hetzner), mais n'a pas eu la mise à jour
> d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue
> - "Scorch" est en France (à Roubais chez OVH): il est affecté par le
> bogue, Ubuntu été mis à jour de 16.04 vers 18.04
> - "Orm" était parmi les serveurs déménagés de Londres (à l'UCL) à
> Amsterdam (chez Equinix): il est affecté par le bogue, Ubuntu été mis à
> jour de 16.04 vers 18.04
>
> La mise à jour d'Ubuntu n'explique pas le rendu incorrect et la
> persistence de ways parasites (marqués comme supprimés dans les "diffs"
> mais qui sont tracés avec une partie des noeuds conservés par ailleurs). Il
> semble que l'impact de cette mise à jour serait que les fichiers "diffs"
> seraient traités alors qu'ils ne sont pas complètement téléchargés : le
> traitement se fait sur une partie seulement des changesets qui sont alors
> tronqués.
>
> Ce n'est apparemment pas un problème de base de données (sur la base de
> données esclave), mais des outils de téléchargement et synchronisation de
> répertoires (je ne sais pas si cela se fait par "rsync" ou pour un script
> shell avec "wget", mais cet outil ne semble pas correctement synchronisé
> avec l'outil qui va ensuite traiter les nouveau diffs reçus et "prêts" pour
> les charger sur la base esclave, une ancienen opération qui était bloquante
> semble être devenue asynchrone et il manque une étape de validation des
> téléchargements de diffs effectivement terminés avant de placer ces
> fichiers dans la file d'attente à traiter pour l'import).
>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org

[Philippe Verdy]

> le serveur utilisé actuellement dépend de la position géographique
> principalement mais peux aussi changer en cas de surcharge,
> info vérifiable en temps réel avec
> https://tile.openstreetmap.org/cgi-bin/debug
> les 2 serveurs ok : Yevaud et Vial
> les 2 serveurs affectés : Scorch et Rhaegal
>

Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch", et
"orm" (et non pas "rhaegal" ou c'est un ancien alias).
- "Yevaud" est encore à Londres (à l'UCL), mais n'a pas eu la mise à jour
d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue
- "Vial" est en Allemagne (à Hetzner), mais n'a pas eu la mise à jour
d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue
- "Scorch" est en France (à Roubais chez OVH): il est affecté par le bogue,
Ubuntu été mis à jour de 16.04 vers 18.04
- "Orm" était parmi les serveurs déménagés de Londres (à l'UCL) à Amsterdam
(chez Equinix): il est affecté par le bogue, Ubuntu été mis à jour de 16.04
vers 18.04

La mise à jour d'Ubuntu n'explique pas le rendu incorrect et la persistence
de ways parasites (marqués comme supprimés dans les "diffs" mais qui sont
tracés avec une partie des noeuds conservés par ailleurs). Il semble que
l'impact de cette mise à jour serait que les fichiers "diffs" seraient
traités alors qu'ils ne sont pas complètement téléchargés : le traitement
se fait sur une partie seulement des changesets qui sont alors tronqués.

Ce n'est apparemment pas un problème de base de données (sur la base de
données esclave), mais des outils de téléchargement et synchronisation de
répertoires (je ne sais pas si cela se fait par "rsync" ou pour un script
shell avec "wget", mais cet outil ne semble pas correctement synchronisé
avec l'outil qui va ensuite traiter les nouveau diffs reçus et "prêts" pour
les charger sur la base esclave, une ancienen opération qui était bloquante
semble être devenue asynchrone et il manque une étape de validation des
téléchargements de diffs effectivement terminés avant de placer ces
fichiers dans la file d'attente à traiter pour l'import).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[john whelan]

I have two concerns about separate tags and they come from my validation
experience with HOT mappers.

The first is duplicate buildings.  When faced with 50 duplicate buildings
in a village if I'm feeling good I'll use the to do list to look at each
pair and delete the one that is the one that least matches the building
outline.  I must confess I do not try to contact the mapper who mapped last
time.  If I or someone like me deletes the outline with the additional add
tags on it the information will be lost.

I note Blake was kind enough to delete some 500 duplicate buildings very
recently very quickly.  He may not have had a changeset discussion on each
one.

The other concern is the use of copying buildings by HOT mappers.  It is
purely a suspicion of mine but I often see a cluster of buildings of
exactly the same size when the underlying buildings are different sizes.
Copy a building with an addr: address code and all the copies will have the
same address.

Something else to check when validating and we know there aren't enough
validators already.  Also its very difficult and time consuming to check
when validating and few validators like validating buildings.

Same topic how do you protect against vandalism?  Someone deliberately
changing the address codes?  Vandalism shouldn't happen but adding the
codes separately adds a vulnerability.

Would someone who imported the codes please address my concerns.

Thanks John

On Fri, 10 Aug 2018, 7:25 pm Martin Koppenhoefer, 
wrote:

>
>
> sent from a phone
>
> > On 10. Aug 2018, at 22:06, Blake Girardot HOT/OSM <
> blake.girar...@hotosm.org> wrote:
> >
> > In the short term, putting a few thousand plus-codes in as addresses,
> > while the local community tries them out. Who know if they work for
> > local folks, but just jamming a few thousand in will allow all the
> > stake holders to trial these codes. Print maps, put signs on
> > buildings, communicate with each other using them.
>
>
> you can use plus codes NOW. It is already working. No need to add
> coordinates in tags.
>
>
> Cheers,
> Martin
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] rendu et maj des tuiles

[marc marc]

Le 10. 08. 18 à 10:58, Jérôme Seigneuret a écrit :
> https://b.tile.openstreetmap.org/18/135336/92001.png
> dernière modification 2018-08-10 10:43:09
> Satut de la tuile : Tile is Clean.
> La date du dernier rendu correspond à la date de modification.  
> avec l'heure en UTC
> y a t-il un problème de gestion des heures locale et UTC? 

les serveurs osm.org et les pages de status sont en UTC.
la majorité des serveurs osm-fr aussi

> Les dalles  expirent sur 7jours glissants. 
> J'aurais mon rendu seulement dans une semaine?

tu peux faire F5 pour demander au cache d'aller vérifier si le serveur 
de rendu à une maj de la tuile (ce qui provoquera une demande maj rendu
si le serveur n'avait pas eu l'occasion de le faire la fois précédente).
Tu peux aussi vider ton cache local au navigateur.
certains font parfois aussi ctrl-f5 pour demander au serveur de rendu
de faire un nouveau de rendu de la tuile (même effet et limitation
que l'utilisation du /dirty)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Martin Koppenhoefer]

sent from a phone

> On 10. Aug 2018, at 22:06, Blake Girardot HOT/OSM  
> wrote:
> 
> In the short term, putting a few thousand plus-codes in as addresses,
> while the local community tries them out. Who know if they work for
> local folks, but just jamming a few thousand in will allow all the
> stake holders to trial these codes. Print maps, put signs on
> buildings, communicate with each other using them.


you can use plus codes NOW. It is already working. No need to add coordinates 
in tags. 


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Martin Koppenhoefer]

sent from a phone

> On 10. Aug 2018, at 22:06, Simon Poole  wrote:
> 
> As I've pointed out before, if OSM supports a specific system, it
> amounts to us picking a winner , and I really don't think that is a good
> idea.


we could support any system that is used and can be used free and openly.


> w3w wants to make money from royalties, google wants to avoid
> paying them. Both have a financial interest in us adopting their
> systems. IMHO when one eventually "wins" we can start supporting it
> then, before one of them pasts the post, it is premature.


While it is true that both parties have economic interest in this, plus codes 
are both, free to use and open source, unlike their 3 words competitor. Even if 
w3w „wins“ we would likely not be interested in promoting them on OSMF servers.

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

Re: [Talk-de] Datum einer Kontrolle vermerken?

[Martin Koppenhoefer]

sent from a phone

> On 11. Aug 2018, at 00:05, Andreas Meier  wrote:
> 
> Gibt es dazu Meinungen? (Wenn das
> schon 100 Mal diskutiert wurde, dann wäre ich für einen Hinweis auf das
> Ergebnis dankbar)


ja, das wurde schon öfters mal vorgeschlagen. 
Es gibt z.B. diese metadaten tags in Benutzung:
https://wiki.openstreetmap.org/wiki/Key%3Asurvey%3Adate
https://wiki.openstreetmap.org/wiki/Key:check_date

und dort auch noch Hinweise auf weitere Varianten.

Es gibt auch Opposition für diese Art tag.


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

Re: [Talk-de] Datum einer Kontrolle vermerken?

[Volker]

Da wirst Du Dich wohl darauf verlassen müssen, dass das Datum der 
letzten Änderung auch das Datum der letzten Überprüfung der Leerungszeit 
ist. Jeder zusätzliche Tag  würde die Datenbank nur mit sinnlosen Daten 
füllen, die nichts mit Geodaten zu tun haben



Am 11.08.2018 um 00:05 schrieb Andreas Meier:

Hallo zusammen,

  


seit einiger Zeit tagge ich auch collection_times bei Briefkästen. Durchaus
häufig sind vorhandene Tags veraltet und falsch. Leider kann ich den
Briefkästen nicht ansehen, ob die collection_times letzte Woche oder vor 4
Jahren zuletzt überprüft wurden. Bestenfalls gibt es ein Datum, wenn es
korrigiert=geändert wurde. Aber wenn jemand kontrolliert hat und es war
richtig, dann bleibt ja nur das ggf. uralte Datum der letzten Änderung
abgreifbar. Daher frage ich mich, ob es sinnvoll wäre, eine Art Zeitstempel
einer Überprüfung als zusätzliches Tag an den Briefkasten zu speichern, z.B.


  


time_stamp_last_check =- oder –

collection_times:last_check =  o.ä.

  


Damit könnte ich mir alle Briefkästen des Dorfes herausfiltern, die z.B.
länger als ein Jahr nicht überprüft wurden und gezielt hinfahren.

  


Das gleiche Prinzip könnte man natürlich auch für Öffnungszeiten von
Geschäften diskutieren oder ähnliches. Gibt es dazu Meinungen? (Wenn das
schon 100 Mal diskutiert wurde, dann wäre ich für einen Hinweis auf das
Ergebnis dankbar)

  


Gruß

Andreas

  


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



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

Re: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org

[marc marc]

Le 11. 08. 18 à 00:23, marc marc a écrit :
> les 2 serveurs ok : Yevaud et Vial
> les 2 serveurs affectés : Scorch et Rhaegal

arf cela concernait le bug osm2pgsql
et non la saturation des files des serveurs de rendu
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-de] Wege des WSV an den Kanälen / tagging

[Andreas Meier]

Ich könnte sowohl mit Track oder Service gut leben, aber aus den bisherigen
Argumenten leitet sich ggf. eine Empfehlung ab:

 

> Die Abgrenzung track zu service: letzteres ist es dann, wenn es keiner
höheren Klasse angehört und wo hinführt, sonst track. 

 

Das finde ich eine sehr schön einfache und praktikable Definition, die ich
bisher so nicht vor Augen hatte.

Aber: 

 

> m.E. auch auf den „Grund“, warum der Weg da ist.

 

Wenn man weiß (woher auch immer), dass der WSV die Wege unterhält, um die
Wasserstraße zu kontrollieren, dann führen die Wege ja ausdrücklich „wo“
hin. Das Ziel ist einfach kein Punktobjekt, sondern eine ausgedehnte
Strecke. Damit wäre „highway = service“ meines Erachtens sowohl vom
Bauchgefühl als auch im Sinne der Definition gerechtfertigt.

 

Damit käme es aber vor allem auf die Abgrenzung ab, welche Wege (inkl.
Zu-/Verbindungswege?) gehören genau zur WSV oder einer entsprechenden
Organisation. Ist das erkennbar oder wird das Service-Netz dann
bruchstückhaft?

 

Gruß

Andreas

 

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Blake Girardot]

On Fri, Aug 10, 2018 at 6:23 PM, Christoph Hormann  wrote:
> On Friday 10 August 2018, Blake Girardot HOT/OSM wrote:
>> > The idea of tagging encoded coordinates is so ridiculous to anyone
>> > with a bit of understanding of computer programming, data
>> > processing and data maintainance that even after ignoring all the
>> > arguments in substance that have been voiced this should be
>> > universally rejected if for no other reason then because it would
>> > make OSM the laughing stock of the whole geodata world.
>>
>> Ok, enough of your overly polite, gentle feedback stuff, tell us how
>> you really feel :)
>
> I am afraid that even after reading it several times i have no idea what
> you want to say with that.

My apologies Christoph, it was sarcasm. You were anything but polite
or gentle with your feedback. I thought it was a friendly, funny way
to de-escalate the discussion and hopefully spark some personal
reflection.

Cheers
blake

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Christoph Hormann]

On Friday 10 August 2018, Blake Girardot HOT/OSM wrote:
> > The idea of tagging encoded coordinates is so ridiculous to anyone
> > with a bit of understanding of computer programming, data
> > processing and data maintainance that even after ignoring all the
> > arguments in substance that have been voiced this should be
> > universally rejected if for no other reason then because it would
> > make OSM the laughing stock of the whole geodata world.
>
> Ok, enough of your overly polite, gentle feedback stuff, tell us how
> you really feel :)

I am afraid that even after reading it several times i have no idea what 
you want to say with that.

-- 
Christoph Hormann
http://www.imagico.de/

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

[OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org

[marc marc]

email séparé pour éviter la noyade avec les autres problèmes :)

ultra résumé pour ceux qui n'ont pas envie de tous lire :
- il y a des bugs en cours de résolution tant sur le rendu osm.org
que sur le rendu osm-fr
- faire un /dirty sur les zoom faible ne sert a rien car ignoré
- les zooms faible ont une fréquence de maj faible.

version longue :

2 soucis majeurs avec le rendu osm.org :
- bug lié à la maj de osm2pgsql lié à maj ubuntu 18.04
Christian a détaillé le bug survenu pour le rendu osm-fr
lors de la maj osm2pgsql, c'est exactement la même cause
qui affecte maintenant le rendu osm.org un peu différemment.
le ticket des maj os
https://github.com/openstreetmap/operations/issues/220
le commit qui aurait été fait il y a 3j
https://github.com/openstreetmap/chef/commit/b2d0ed3e9e4f2fc899db7265a23156d5dd5cf139
la reconstruction du fichier est toujours en cours

- les files d'attente des différents serveur de rendu sont souvent 
pleine en journée. donc si on modifie quelque chose en journée,
la modif est bien sauvegardée mais la tuile n'est pas automatiquement 
maj. la prochaine visite de la page après le délais du cache provoquera 
une demande de maj de la tuile (sous réserve qu'il y ai de la place)
maj qui serra visible tout de suite si la tuile est calculée rapidement 
(par ex en z19) ou ne serra elle aussi visible qu'à l'expiration de 
l'ancienne tuile si la maj n'a pas pu se faire assez vite
la file d'attente des serveurs de rendu osm.org sont visible ici
https://munin.openstreetmap.org/renderd-day.html
le serveur utilisé actuellement dépend de la position géographique 
principalement mais peux aussi changer en cas de surcharge,
info vérifiable en temps réel avec
https://tile.openstreetmap.org/cgi-bin/debug
les 2 serveurs ok : Yevaud et Vial
les 2 serveurs affectés : Scorch et Rhaegal

2 soucis majeurs avec le rendu osm-fr
- lors des soucis liés à la maj osm2pgsql, une série de tache 
automatique ont été désactivées et tout n'est pas encore repris
en route, par exemple le rafraîchissement des zoom 1-11
Christian étant en vacances, je suis entrain de voir ce qui reste
à faire, une maj des tuiles 1 ä 11 est en cours depuis des heures
et cela prendra peut-être encore des heures. donc patience...
- il y a qlq abus des tuiles osm-fr ce qui sature régulièrement la file 
d'attente, provoquant le même problème que décrit ci-dessus avec osm.org
la file d'attente du serveur de rendu osm-fr est visible sur
http://munin.openstreetmap.fr/osm25.openstreetmap.fr/osm25.openstreetmap.fr/renderd_queue.html

ce qui est volontaire et non un bug :
- /dirty sur les zoom faible est ultra gourmand en ressource
pour éviter que le serveur passe son temps sur ces niveaux,
sur osm-fr les /dirty zoom 1 à 11 sont ignoré.
osm.org a le même genre de politique (je ne connais pas par cœur
le niveau de zoom, c'est peut-être sur le wiki) avec maj le we.
Il n'y a donc pas de bug sur le z9 ne montre pas une modif récente.
Effacer et recréer les objets posant problème de rendu est 
contre-productif, cela ne fait que provoquer une expiration et un rendu 
supplémentaire en perdant au passage l'historique des objets.

En espérant avoir été utile et ne pas avoir dit de connerie
malgré que je me suis relu :)

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

Re: [Talk-dk] Konstruktioner i vand

[Niels Elgaard Larsen]

Ja, men det er måske ikke rigtigt en breakwater.
Det er mere en estakade. Men jeg ved heller ikke hvordan det skulle tagges.

Afspærringen ved Holmen er tagget som:

barrier fence
fence_type  chain_link
wire_fence  stockade

seamark:type=wall
er måske passende.

Ifølge wikien er det:

A natural or man-made barrier used as an enclosure or boundary or for
protection.

Den 10-08-2018 kl. 23:46 skrev Troels Arvin:
> Hej,
> 
> Jeg skrev bl.a.:
>> I København er der i nordlig regning fra Slusen i Kalveboderne nogle
>> konstruktioener ude i vandet, som jeg ikke lige kan regne ud, hvordan
>> man kan/bør indtegne:
>>
>> https://binged.it/2KIfQe7
>> http://troels.arvin.dk/osm/evidence/sluse_vand-ting/vand0.jpg
> 
> [...]
> 
> Ups. Jørgen Elgaard Larsen tegnede det ind for syv år siden:
> https://www.openstreetmap.org/way/108849029/
> history#map=19/55.64313/12.55270
> 
> Glem, hvad jeg skrev.
> 

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

[Talk-de] Datum einer Kontrolle vermerken?

[Andreas Meier]

Hallo zusammen,

 

seit einiger Zeit tagge ich auch collection_times bei Briefkästen. Durchaus
häufig sind vorhandene Tags veraltet und falsch. Leider kann ich den
Briefkästen nicht ansehen, ob die collection_times letzte Woche oder vor 4
Jahren zuletzt überprüft wurden. Bestenfalls gibt es ein Datum, wenn es
korrigiert=geändert wurde. Aber wenn jemand kontrolliert hat und es war
richtig, dann bleibt ja nur das ggf. uralte Datum der letzten Änderung
abgreifbar. Daher frage ich mich, ob es sinnvoll wäre, eine Art Zeitstempel
einer Überprüfung als zusätzliches Tag an den Briefkasten zu speichern, z.B.


 

time_stamp_last_check =- oder –

collection_times:last_check =  o.ä.

 

Damit könnte ich mir alle Briefkästen des Dorfes herausfiltern, die z.B.
länger als ein Jahr nicht überprüft wurden und gezielt hinfahren.

 

Das gleiche Prinzip könnte man natürlich auch für Öffnungszeiten von
Geschäften diskutieren oder ähnliches. Gibt es dazu Meinungen? (Wenn das
schon 100 Mal diskutiert wurde, dann wäre ich für einen Hinweis auf das
Ergebnis dankbar)

 

Gruß

Andreas

 

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Paul Norman]

On 2018-08-10 1:06 PM, Blake Girardot HOT/OSM wrote:

Learning the real world use cases and where the proper technological
solutions work and if there really genuinely are places where dynamic
generation is just not possible.

This seems totally in line with things done in the past and should
work well here.


Speaking as a developer, it's much easier to add PlusCode support 
properly than to try and parse another address tag. Don't add them 
thinking it makes it easier.


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Andrew Harvey]

On 10 August 2018 at 22:47, Michael Reichert  wrote:
>
> There is no need for this data in OSM because the data can be retrieved
> automatically from latitude and longitude (plain coordinates) which are
> already assigned to anything which has a location on the planet.
>
> Adding Plus Code tags to OSM objects is as useful as adding latitude=*
> and longitude=* or any other coordinate system which can be calculated
> from latitude and longitude.
>
> This import should be reverted.
>

I agree, unless people start putting up signs of the Plus Codes outside
their house and you're mapping that as the on the ground housenumber. I
don't agree with importing these, it just adds unnecessary bloat to the
database size.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-dk] Konstruktioner i vand

[Troels Arvin]

Hej,

Jeg skrev bl.a.:
> I København er der i nordlig regning fra Slusen i Kalveboderne nogle
> konstruktioener ude i vandet, som jeg ikke lige kan regne ud, hvordan
> man kan/bør indtegne:
> 
> https://binged.it/2KIfQe7
> http://troels.arvin.dk/osm/evidence/sluse_vand-ting/vand0.jpg

[...]

Ups. Jørgen Elgaard Larsen tegnede det ind for syv år siden:
https://www.openstreetmap.org/way/108849029/
history#map=19/55.64313/12.55270

Glem, hvad jeg skrev.

-- 
Troels


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Matt Williams]

On 10 August 2018 at 21:06, Blake Girardot HOT/OSM
 wrote:
> Hi Frederick,
>
> I appreciate the thoughtful reply.
>
> I think for the most part we all agree on the technology solution
> really looking like the best option. But it is the best option in the
> medium and long term.
>
> In the short term, putting a few thousand plus-codes in as addresses,
> while the local community tries them out. Who know if they work for
> local folks, but just jamming a few thousand in will allow all the
> stake holders to trial these codes. Print maps, put signs on
> buildings, communicate with each other using them.

But exactly *how* does adding the OLC as a tag to the object in OSM
help them do that? Why do they need them as tags to do any of printing
maps, putting signs on buildings or communicating with others using
them? What actual process, manual or programmatic, are you imagining
here? The only way to make use of OSM is to write software which
processes the database (creating geocoders, rendering maps etc). That
software could *so* easily inject OLCs in whatever way you want. The
only possible reason to have OLCs as a tag is if people are reading
the raw XML OSM data as text printed on paper and want to find out
what OLC a certain way has. No one does that.

To make any meaningful use of these tags they will have to write
software designed to extract the OLCs and interpret them at which
point they could simply *generate* the tags at point-of-use (they are
effectively just an encoded lat/lon). This avoids any onerous manual
tagging and makes anything they create immediately useful as widely as
they wish.

I agree with others in this discussion that it's bizarre that anyone
thinks that adding these codes as tags to all the buildings in a city
is a sensible thing to do or a good use of anyone's time.

Matt

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

Re: [OSM-talk-fr] interruption coupure d'une piste cyclable

[David Crochet]

Bonjour


Le 10/08/2018 à 23:30, lenny.libre a écrit :

faut-il descendre de vélo pour suivre ce chemin, prendre la route ? 


légalement oui


quels attributs mettre ? 


cela redevient un traditionnel trottoir donc

highway=footway
footway=sidewalk

Cordalement

--
David Crochet


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

[OSM-talk-fr] interruption coupure d'une piste cyclable

[lenny.libre]

Bonsoir,

Il y a une piste https://www.openstreetmap.org/way/229173276

en arrivant au sud, se trouve un panneau de type C114 indiquant la fin 
d'une voie conseillée et réservée aux cyclistes


https://www.mapillary.com/map/im/B_fw7x1IdkUKD4J3IQaRyQ

La piste reprend au fond (dans la zone actuellement en travaux)

https://www.mapillary.com/map/im/AUZjjsmNesyfZIIgGIwPYg

j'avais coupé en deux tronçons, la piste qui descend vers le sud et 
celle qui va vers l'est, mais les attributs ne sont plus valable sur 
cette portion

https://www.openstreetmap.org/way/511352767
Des cyclistes l'empruntent, passant entre les arrêts de bus, l'espace 
vert, les panneaux d'information et les piétons
mais comment comprendre la signalisation : faut-il descendre de vélo 
pour suivre ce chemin, prendre la route ? quels attributs mettre ?


cordialement
Leni

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Blake Girardot]

On Fri, Aug 10, 2018 at 4:35 PM, Simon Poole  wrote:

> That is not the point, for the goog it is a net win simply avoiding
> systems being adopted for which they potentially would have to pay
> royalties for.

Is that not the reason OSM was started in the first place?   :)

But I agree, I hope all the folks and organizations that contribute to
OpenStreetMap profit from it in some way.

Cheers
blake

-- 

Blake Girardot
OSM Wiki - https://wiki.openstreetmap.org/wiki/User:Bgirardot
HOTOSM Member - https://hotosm.org/users/blake_girardot
skype: jblakegirardot

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Craig Wallace]

On 2018-08-10 21:06, Simon Poole wrote:

While the goals sound worthy, it is unclear if any of the grid systems
(w3w, plus codes and so on) deliver on their promises and have any
traction outside of people in countries with established addressing
systems trying to push them as solutions for countries without.

As I've pointed out before, if OSM supports a specific system, it
amounts to us picking a winner , and I really don't think that is a good
idea. w3w wants to make money from royalties, google wants to avoid
paying them. Both have a financial interest in us adopting their
systems. IMHO when one eventually "wins" we can start supporting it
then, before one of them pasts the post, it is premature.


Or OSM could support a variety of different coordinate systems (so long 
as they are free/open).
It is possible to search for latitude/longitude on osm.org, why not also 
allow UTM/MGRS, Plus codes, Geohash etc.

OSM doesn't have to endorse one particular system as the best.

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[john whelan]

Let us just recap.  Open Location Code can be used in OSMand today for
anything in Openstreetmap.

It both shows the OLC code and can search for the OLC code so to my mind
OLC is already available in OpenStreetMap and can be used operationally
today.  There is no need to add additional tags to the database.

If additional tags are added how do we know the data is correct?  How can
we be sure a transcription error has not occurred.

Purely from a data quality point of view I would recommend the data is not
duplicated.

I understand that in Tanzania a lot of work has been done to add them.
Fine they didn't understand the issues nor did they talk to anyone first.
The issue here is education nothing else.

I would suggest we add it to the search options on the web site and get on
with life.

Cheerio John



On Sat, Aug 11, 2018, 4:38 AM Simon Poole  wrote:

>
>
> Am 10.08.2018 um 22:18 schrieb Oleksiy Muzalyev:
> > ...
> >
> > The OLC is Open Source with the Apache 2.0 license. I have a doubt
> > though, - cannot Google in couple of years say: "We change the license
> > and not one has to pay for the OLC usage?" I am not a lawyer and I do
> > not know such subtleties.
> >
> >
> That is not the point, for the goog it is a net win simply avoiding
> systems being adopted for which they potentially would have to pay
> royalties for. They don't actually need to charge for their system to
> have a win. I'm not making a moral judgement here, improving your bottom
> line one way or the other, is exactly the same.
>
> Simon
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Blake Girardot]

On Fri, Aug 10, 2018 at 4:30 PM, Simon Poole  wrote:
>
>
> Am 10.08.2018 um 22:14 schrieb Blake Girardot HOT/OSM:
>> ...
>> Our community should have a say in what wins, we can try them both,
>> but here is a local group asking us to try plus codes and there is a
>> lot of momentum behind it.
> In the case of w3w one can actually make a technical case for including
> them in OSM, in the case of plus codes, as has been pointed out. that is
> absurd. If a community wants to try out one or the other, more power to
> them, I just fail to see what that has to do with OSM.
>
> Simon
>
> PS: naturally the momentum has a lot to do with very very very deep pockets
>

Oh absolutely. Vendors supporting OSMF is critical. If a donor wants
to sponsor particular improvements, I 100% support that if the
community generally supports the improvements.

I think we are all agreeing it has really good, lightweight, dynamic
implementation characteristics. That is a great technical criteria.

I do not support w3w (full disclosure founder of w3w has been a
supporter of HOT, an organization I work for, these are my opinions
only). It is a fun idea, but I think it does not work for a number of
reasons. But super cool idea.

But while I do not like the w3w solution, if they wanted to support
OSMF to improve w3w support in osm core and the ecosystem of tools I
would be all for giving it the exact same trial if the community
agreed.

But generally, I think plus codes are coming out looking quite good
from a technical perspective, both dynamically generated and static
uses like address signs and printed maps.

Cheers,
blake



-- 

Blake Girardot
OSM Wiki - https://wiki.openstreetmap.org/wiki/User:Bgirardot
HOTOSM Member - https://hotosm.org/users/blake_girardot
skype: jblakegirardot

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

[Talk-dk] Konstruktioner i vand

[Troels Arvin]

Hej,

I København er der i nordlig regning fra Slusen i Kalveboderne nogle 
konstruktioener ude i vandet, som jeg ikke lige kan regne ud, hvordan man 
kan/bør indtegne:

https://binged.it/2KIfQe7
http://troels.arvin.dk/osm/evidence/sluse_vand-ting/vand0.jpg

Sådan ser det ud, set inde fra slusen:
http://troels.arvin.dk/osm/evidence/sluse_vand-ting/vand1.jpg
http://troels.arvin.dk/osm/evidence/sluse_vand-ting/vand2.jpg
http://troels.arvin.dk/osm/evidence/sluse_vand-ting/vand3.jpg

Så der er altså nogle wires spændt ud mellem nogle træ-konstruktioner, 
som leder skibe ind til slusen.

Er der nogen, der har bud på, hvordan dét kan indtegnes?

-- 
Troels


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Simon Poole]

Am 10.08.2018 um 22:18 schrieb Oleksiy Muzalyev:
> ...
>
> The OLC is Open Source with the Apache 2.0 license. I have a doubt
> though, - cannot Google in couple of years say: "We change the license
> and not one has to pay for the OLC usage?" I am not a lawyer and I do
> not know such subtleties.
>
>
That is not the point, for the goog it is a net win simply avoiding
systems being adopted for which they potentially would have to pay
royalties for. They don't actually need to charge for their system to
have a win. I'm not making a moral judgement here, improving your bottom
line one way or the other, is exactly the same.

Simon




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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Simon Poole]

Am 10.08.2018 um 22:14 schrieb Blake Girardot HOT/OSM:
> ...
> Our community should have a say in what wins, we can try them both,
> but here is a local group asking us to try plus codes and there is a
> lot of momentum behind it.
In the case of w3w one can actually make a technical case for including
them in OSM, in the case of plus codes, as has been pointed out. that is
absurd. If a community wants to try out one or the other, more power to
them, I just fail to see what that has to do with OSM.

Simon

PS: naturally the momentum has a lot to do with very very very deep pockets




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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Blake Girardot HOT/OSM]

>
> I think it will work like this - a dispatcher at an ambulance service says
> during a call: "We will not go to your house unless you provide the
> plus-code. Bot the Google Maps and OpenStreetMap websites allow to generate
> the plus-code for a house." I mean it will not work without a leadership.
>
> The OLC is Open Source with the Apache 2.0 license. I have a doubt though, -
> cannot Google in couple of years say: "We change the license and not one has
> to pay for the OLC usage?" I am not a lawyer and I do not know such
> subtleties.

They can't change the license to the code released now. Download it,
it is yours to use in accordance with the license it was released
under forever.

If they enhance it later, add new code, rewrite it, etc, that can be
under a different license.

But what works right now (or until a license change) will keep working
assuming you have the hardware and software to run it.

cheers
blake



-- 

Blake Girardot
Humanitarian OpenStreetMap Team

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Oleksiy Muzalyev]

On 10.08.18 23:06, Simon Poole wrote:

While the goals sound worthy, it is unclear if any of the grid systems
(w3w, plus codes and so on) deliver on their promises and have any
traction outside of people in countries with established addressing
systems trying to push them as solutions for countries without.

As I've pointed out before, if OSM supports a specific system, it
amounts to us picking a winner , and I really don't think that is a good
idea. w3w wants to make money from royalties, google wants to avoid
paying them. Both have a financial interest in us adopting their
systems. IMHO when one eventually "wins" we can start supporting it
then, before one of them pasts the post, it is premature.

Simon





I think it will work like this - a dispatcher at an ambulance service 
says during a call: "We will not go to your house unless you provide the 
plus-code. Bot the Google Maps and OpenStreetMap websites allow to 
generate the plus-code for a house." I mean it will not work without a 
leadership.


The OLC is Open Source with the Apache 2.0 license. I have a doubt 
though, - cannot Google in couple of years say: "We change the license 
and not one has to pay for the OLC usage?" I am not a lawyer and I do 
not know such subtleties.


Best regards,

Oleksiy

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Blake Girardot HOT/OSM]

On Fri, Aug 10, 2018 at 4:06 PM, Simon Poole  wrote:
>
> While the goals sound worthy, it is unclear if any of the grid systems
> (w3w, plus codes and so on) deliver on their promises and have any
> traction outside of people in countries with established addressing
> systems trying to push them as solutions for countries without.
>
> As I've pointed out before, if OSM supports a specific system, it
> amounts to us picking a winner , and I really don't think that is a good
> idea. w3w wants to make money from royalties, google wants to avoid
> paying them. Both have a financial interest in us adopting their
> systems. IMHO when one eventually "wins" we can start supporting it
> then, before one of them pasts the post, it is premature.
>
> Simon

Hi Simon, what should "win" is the system that works the best. w3w has
been tried, is being tried, we can try that too, but what should win
is what is open, is fit for the purpose, can and will be used and is
non propitiatory.

Our community should have a say in what wins, we can try them both,
but here is a local group asking us to try plus codes and there is a
lot of momentum behind it.

Cheers,


-- 

Blake Girardot
Humanitarian OpenStreetMap Team

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Simon Poole]

While the goals sound worthy, it is unclear if any of the grid systems
(w3w, plus codes and so on) deliver on their promises and have any
traction outside of people in countries with established addressing
systems trying to push them as solutions for countries without.

As I've pointed out before, if OSM supports a specific system, it
amounts to us picking a winner , and I really don't think that is a good
idea. w3w wants to make money from royalties, google wants to avoid
paying them. Both have a financial interest in us adopting their
systems. IMHO when one eventually "wins" we can start supporting it
then, before one of them pasts the post, it is premature.

Simon





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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Blake Girardot HOT/OSM]

Hi Frederick,

I appreciate the thoughtful reply.

I think for the most part we all agree on the technology solution
really looking like the best option. But it is the best option in the
medium and long term.

In the short term, putting a few thousand plus-codes in as addresses,
while the local community tries them out. Who know if they work for
local folks, but just jamming a few thousand in will allow all the
stake holders to trial these codes. Print maps, put signs on
buildings, communicate with each other using them.

While that goes on, the other technological support can happen if
people wish to do that or maybe we find some funding to add support to
some of the most popular community apps and the nominatum.

But we will still be learning from the small scale tag based trials.

Learning the real world use cases and where the proper technological
solutions work and if there really genuinely are places where dynamic
generation is just not possible.

This seems totally in line with things done in the past and should
work well here.

I am fairly sure I know the local on the ground community that might
like to explore this. The Mugumu Safe House
http://www.tanzdevtrust.org/portfolio-item/mugumu-safe-house-for-girls/
who have to perform rescues. They are first responders to gender based
sexual violence and might be just the sort of organization that would
like to start using plus-codes, and they are local and understand the
local culture and customs better than any other living group of
people.

So, lets take this all down a degree and Vao and whomever else is
interested and formalize the testing of plus codes in a rural tanzania
setting.

But lets leave the address that are imported, they are hurting nothing
at the moment and we should look at them and review them and learn
from them being there now.

Respectfully
blake



On Fri, Aug 10, 2018 at 3:26 PM, Frederik Ramm  wrote:
> Blake,
>
> On 10.08.2018 19:23, Blake Girardot wrote:
>> I think an approach based on local buy-in, with a small scale test of
>> adding the PlusCode address to the objects is the fastest, OSM'ish way
>> forward.
>
> Christoph was a bit harsh in his response but I think he is right on teh
> fundamentals, and I urge you to reconsider.
>
> As I have explained in another post just a few minutes ago, taking the
> "adding tags to OSM" approach is a cynical form of aid - it makes people
> using it depend on your aid. It wastes effort with those adding the
> data, it wastes storage space in OSM, it has *nothing*, absolutely
> nothing going for it.
>
> The sensible approach is to add the logic that converts plus codes to
> locations and vice versa to those places where people interface with the
> map - be that the osm.org web site, or the offline application they're
> using, or the machine that prints a map. It would not be difficult to
> modify e.g. the humanitarian map style to print plus codes onto
> buildings, computing them on the fly, if that's desired. Doing this
> means you develop it once and it is immediately usable everywhere by
> everyone. That is the only sensible approach. Otherwise you'll be stuck
> running one project after the other ("add plus codes for X community",
> "add plus codes for Y community", etc.), and not only that: The generic
> approach will automatically work for everything built in the future. It
> can be used to address not only houses but wells, mountains, bays, even
> trees. It is better in *every* respect.
>
> We must let reason prevail here and not do something on a whim based on
> a misunderstanding of how things work.
>
> It is sad that it has come to a point where some people seem to have
> already built "projects" around importing plus codes in a way that
> everyone here would have told them is the least useful of all, had they
> botehred to ask! Let us stop the madness before it spreads further, and
> work on doing it right.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



-- 

Blake Girardot
Humanitarian OpenStreetMap Team

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Blake Girardot HOT/OSM]

On Fri, Aug 10, 2018 at 1:46 PM, Christoph Hormann  wrote:

> The idea of tagging encoded coordinates is so ridiculous to anyone with
> a bit of understanding of computer programming, data processing and
> data maintainance that even after ignoring all the arguments in
> substance that have been voiced this should be universally rejected if
> for no other reason then because it would make OSM the laughing stock
> of the whole geodata world.

Ok, enough of your overly polite, gentle feedback stuff, tell us how
you really feel :)

Cheers,
blake

-- 

Blake Girardot
Humanitarian OpenStreetMap Team

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Craig Wallace]

On 2018-08-10 20:11, Frederik Ramm wrote:

The approach that I - and everyone else who applies the same logic -
propose, is:

1. A zooms to their house on OSMAnd.
2. A clicks on the house to invoke the plus code computation function in
OSMAnd.
3. OSMAnd displays the plus code.
4. A tells B the plus code.
5. B enters the plus code into OSMAnd, and OSMAnd applies the reverse
computation function.
6. B knows where to go.

This approach requires extra functionality in OSMAnd to apply the plus
code computation, but libraries and code for that exist. This approach
does NOT require that someone else has added the particular location to
OSM before - it works everywhere on the planet. Also, this approach does
not require OSM to store all the plus codes.
OsmAnd already supports Plus codes. You can do exactly this already. No 
extra coding required.
Go to general settings, then coordinate format, then set 'OLC'. Then it 
will display Plus codes for any location on the map that you pick. It 
works fine for any object on the map, or even blank spaces if you want. 
No need for any specific tags.


Craig

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Oleksiy Muzalyev]

On 10.08.18 22:26, Frederik Ramm wrote:

...
The sensible approach is to add the logic that converts plus codes to
locations and vice versa to those places where people interface with the
map - be that the osm.org web site, ...


This is the focal point of this discussion. Do we want to accept the the 
Open Location Code technology at the OSM community?


It is clear that a plus-code can be converted to coordinates and vice 
versa by a formula. But that does not exist. I tried to enter a plus 
code into search box at the OSM.org, it does not work.


It works at Google Maps, but that village Zeze in Tanzania is not mapped 
yet at the Google Maps at all. But it is well mapped at the OSM.org.


brgds

O.


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Barry Hunter]

On Fri, Aug 10, 2018 at 8:18 PM Oleksiy Muzalyev <
oleksiy.muzal...@bluewin.ch> wrote:

> On 10.08.18 21:07, Mark Wagner wrote:
> > On Fri, 10 Aug 2018 09:32:50 -0700
> > Vao Matua  wrote:
> >
> >> Plus code can be calculated on the fly, but if they are
> >> to be used we will need to have hardcopy maps with the addresses that
> >> can be used to direct aid workers to a specific location.
> > Plus codes form a hierarchical grid, so supporting them on hardcopy
> > maps can easily be done when the maps are prepared for printing.
> >
> > I don't know if you're familiar with the UGSG topo maps, but if you
> > aren't, I recommend looking at one of the 1:24000-scale maps from the
> > late 1970s/early 1980s.  It's got three location grids on it: UTM
> > coordinates and latitude/longitude markings on the outside, and PLSS
> > township/range/section markings on the map itself.  Adding a plus-code
> > grid to the map would be no problem, and wouldn't require importing
> > billions of tags into OSM.
> >
> It is absolutely clear. A plus-code is generated by a mathematical
> formula from coordinates almost instantaneously, and vice versa.
>
> The same as say the binary code is generated from the C++ programming
> language, or words are created from letters, etc. It is just another
> layer of abstraction, which makes it easier to perform a task.
>
> In principle it is possible to write a computer program in assembler,
> the low-level programming language. But it is a bit easier to do it in
> C++, Java, PHP, etc. The same is here.



> It is easier to memorize a
> plus-code, to transmit over the telephone, to put it on the address
> plaque, etc.


So do that *now*. It works.

The 'receiver' just needs a program (unless they know how to decode in
head!) to decode it and use it.

OSMAnd is one example quoted that can ALREADY decode it.

https://osmand.net/blog?id=osmand-2-6-released

Support for Open Location Code (OLC)

OsmAnd now also supports the Open Location Code (OLC) way of representing
coordinates. OLC coordinates are a combination of letters and numbers, and
is considered to be handled easier than the traditional latitude and
longitude coordinates. Please read more about OLC here
. You can now also search locations via this
code in the Search menu - Address - Coordinates Search, there select 'OLC'
under Coordinate format. Also, the context menus of any location selected
now displays OLC in addition to Latitude and longitude.


Nominatim, or any other 'search box' or geocoder could just as easily
implement the decoding of the Open Location Code.

It's a tiny (in the grand scheme of things) but of code to add to the
application.







> Yes, it is possible to do the same thing with coordinates'
> digits, but nobody does it.
>

How many people do enter a coordinate in the OSM serach box? Apart from map
geeks not many.

With little effort the box could easily understand a plus code.



It doesnt need millions of tags imported into OSM database to enable it.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Frederik Ramm]

Blake,

On 10.08.2018 19:23, Blake Girardot wrote:
> I think an approach based on local buy-in, with a small scale test of
> adding the PlusCode address to the objects is the fastest, OSM'ish way
> forward.

Christoph was a bit harsh in his response but I think he is right on teh
fundamentals, and I urge you to reconsider.

As I have explained in another post just a few minutes ago, taking the
"adding tags to OSM" approach is a cynical form of aid - it makes people
using it depend on your aid. It wastes effort with those adding the
data, it wastes storage space in OSM, it has *nothing*, absolutely
nothing going for it.

The sensible approach is to add the logic that converts plus codes to
locations and vice versa to those places where people interface with the
map - be that the osm.org web site, or the offline application they're
using, or the machine that prints a map. It would not be difficult to
modify e.g. the humanitarian map style to print plus codes onto
buildings, computing them on the fly, if that's desired. Doing this
means you develop it once and it is immediately usable everywhere by
everyone. That is the only sensible approach. Otherwise you'll be stuck
running one project after the other ("add plus codes for X community",
"add plus codes for Y community", etc.), and not only that: The generic
approach will automatically work for everything built in the future. It
can be used to address not only houses but wells, mountains, bays, even
trees. It is better in *every* respect.

We must let reason prevail here and not do something on a whim based on
a misunderstanding of how things work.

It is sad that it has come to a point where some people seem to have
already built "projects" around importing plus codes in a way that
everyone here would have told them is the least useful of all, had they
botehred to ask! Let us stop the madness before it spreads further, and
work on doing it right.

Bye
Frederik

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

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

Re: [OSM-talk-fr] bug de rendu sur les lignes de terrain de sport sur le rendu osmfr

[Eric Brosselin - Osm]

Bonjour,

Je l'ai signalé le 18 juillet dernier à Christian Quest (cf ci-dessous)

Le problème est apparu suite à la relance du serveur du rendu FR.


Oups... je regarde d'où ça vient, car les requêtes SQL n'ont pas 
changé et la feuille de style non plus.


Sûrement un effet de bord inattendu des nombreuses mises à jour récentes !



Le 18/07/2018 à 13:56, Eric Brosselin - Osm a écrit :

Le 18/07/2018 à 00:31, Christian Quest a écrit :
C'est bien normale et on n'a rien à cacher, même nos pétouilles et 
cagades :)


Il me semble qu'il y a un problème avec les terrains de sports

Voir >>> https://framapic.org/nBQk6DArfag4/PopHrAb631dc.jpg



-- Christian Quest - OpenStreetMap France




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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Oleksiy Muzalyev]

On 10.08.18 21:07, Mark Wagner wrote:

On Fri, 10 Aug 2018 09:32:50 -0700
Vao Matua  wrote:


Plus code can be calculated on the fly, but if they are
to be used we will need to have hardcopy maps with the addresses that
can be used to direct aid workers to a specific location.

Plus codes form a hierarchical grid, so supporting them on hardcopy
maps can easily be done when the maps are prepared for printing.

I don't know if you're familiar with the UGSG topo maps, but if you
aren't, I recommend looking at one of the 1:24000-scale maps from the
late 1970s/early 1980s.  It's got three location grids on it: UTM
coordinates and latitude/longitude markings on the outside, and PLSS
township/range/section markings on the map itself.  Adding a plus-code
grid to the map would be no problem, and wouldn't require importing
billions of tags into OSM.

It is absolutely clear. A plus-code is generated by a mathematical 
formula from coordinates almost instantaneously, and vice versa.


The same as say the binary code is generated from the C++ programming 
language, or words are created from letters, etc. It is just another 
layer of abstraction, which makes it easier to perform a task.


In principle it is possible to write a computer program in assembler, 
the low-level programming language. But it is a bit easier to do it in 
C++, Java, PHP, etc. The same is here. It is easier to memorize a 
plus-code, to transmit over the telephone, to put it on the address 
plaque, etc. Yes, it is possible to do the same thing with coordinates' 
digits, but nobody does it.


So people try to find another solutions for places which do not have 
street-name addresses, to create another layer of abstraction. 
Coordinates themselves are created from numbers and are also just an 
abstraction, but not convenient enough for most people.


Best regards,

Oleksiy



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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Frederik Ramm]

Hi,

I am very surprised that this discussion is not dead yet. To me, this is
like one person saying 1+1 is 2 and the other person saying 1+1 is 3.
This is something that should not be a matter of opinion; this is a
matter of logic.

Vao, when you write:

> My objective is to give addresses to people who will never have one.

that's totally ok, and can be done with OSM and plus codes, no question!

The issue is just: Should the algorithm that converts lat/lon into plus
codes be applied "centrally" and the result of the computation stored in
OSM (which seems to be your approach), or should the computation instead
happen at the point where a human being interfaces with OSM.

To take the example of OSMAnd and make it very clear, step by step.

Let's assume we have two people, each using OSMAnd, and one person (A)
wants to communicate to the other person (B) where they live.

Your approach goes like this:

1. A zooms to their house on OSMAnd.
2. A clicks on the house to somehow bring up all tags the house has.
3. One of these tags is the plus code, because it has been added at
another time by a third party.
4. A tells B the plus code.
5. B invokes a search function on their OSMAnd, and OSMAnd searches for
an object that has the given plus code.
6. B knows where to go.

This approach requires extra functionality in OSMAnd (namely: evaluating
the plus code tags), and it requires a third party to have added the
plus code for the location in question beforehand. It also requires OSM
to store the plus codes.

The approach that I - and everyone else who applies the same logic -
propose, is:

1. A zooms to their house on OSMAnd.
2. A clicks on the house to invoke the plus code computation function in
OSMAnd.
3. OSMAnd displays the plus code.
4. A tells B the plus code.
5. B enters the plus code into OSMAnd, and OSMAnd applies the reverse
computation function.
6. B knows where to go.

This approach requires extra functionality in OSMAnd to apply the plus
code computation, but libraries and code for that exist. This approach
does NOT require that someone else has added the particular location to
OSM before - it works everywhere on the planet. Also, this approach does
not require OSM to store all the plus codes.

The only thing that approach A has going for it is that if someone has
the means to access OSM, but has no means to invoke the plus code
computation, they can still read the plus code from the tag. But I
struggle to think of a scenario like that.

I think that approach B is not only better, it is the only sane
approach. Approach A makes users dependent on the goodwill of someone
who uploads all the tags to OSM. Approach B makes this "someone"
unnecessary. When used in a humanitarian/development context, approach A
represents the old style of making people dependent on aid (dependent on
a third party running a plus code import project), whereas approach B is
making users independent. Approach A is the wrong approach for everyone.

> It is interesting that this effort for
> addressing is being trashed because it is savvy technology.

You are misreading me and many others here. Plus codes may be savvy
technology (albeit I can see how the dependency on latin alphabet may be
putting some people off). Plus codes themselves are not under attack
here; what is being criticized is using plus codes to do "approach A",
and *that* is very certainly not savvy!

I and many others have said this a few times in this thread, and I have
the impression that it has not really become clear. I hope that this
lengthy post has managed to explain it, and I am sure that once you have
thought this through you will see that - *especially* from a development
aid perspective - approach A is the last thing you want!

Bye
Frederik

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

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

[OSM-talk-be] int_ref, ref spelling, no space between letter and number....

[Jakka]

Hi,
Where can I see and read what is the correct spelling of the E and other 
road network like A?

Is there a space between the letter and number?
The wiki 
https://wiki.openstreetmap.org/wiki/WikiProject_Europe/E-road_network 
and https://en.wikipedia.org/wiki/International_E-road_network are not 
clear about that..
See the mapillary 
https://www.mapillary.com/map/im/vEtPrDgYQ9nVD2kfehABQg example there 
are no spaces so we should adapt all those tags?
I see that most of int_ref is with space en same ref an nat_ref 
without But not always.



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

[Talk-br] Doações para a futura associação, favor declarar

[Peter Krauss]

Prezados colaboradores e colaboradoras empenhados na  futura Associação OSM
Brasil,


Abrindo tópico aqui no Talk-BR para deixarmos registrado qualquer tipo de
patrimônio ou hora-trabalho a ser contabilizado como doação para a
Associação.

O dia que ela passar a existir (registro de ata de fundação no cartório)
e/ou o dia que ela estiver operando com um CNPJ.

O mais importante por hora, antes da fundação, é registrar aqui
publicamente o compromisso de transferência de direitos de propriedade...
Por exemplo o domínio OPENSTREETMAP.COM.BR ,
já que a ata de fundação ou mesmo o anexo do Estatuto precisarão citar esse
tipo de patrimônio inicial.


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Jmapb]

On 8/10/2018 1:33 PM, Barry Hunter wrote:



But in the case of a long driveway wouldnt the address be attached to 
the entryway (so that directions etc, can route to the right location)?


This isn't very common, and there's no documentation of this practice on 
the addr or service=driveway wiki pages. (There is mention of adding 
addr:* tags to an "entrance/gate", but no suggestion as to when this 
should be done.)


From what I've seen, usually the house at the end of the driveway would 
get the addr:* tags, and the routing engine would route down the 
driveway -- or, if the driveway is tagged access=private, to the nearest 
spot on the public road, which is *usually* pretty close to where the 
driveway starts.


In your scenario, what gets the addr: tags? The driveway itself, or the 
intersection node?


J





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

[Talk-ca] weeklyOSM #420 2018-07-31-2018-08-06

[weeklyteam]

The weekly round-up of OSM news, issue # 420,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10586/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[OSM-talk] weeklyOSM #420 2018-07-31-2018-08-06

[weeklyteam]

The weekly round-up of OSM news, issue # 420,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10586/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-us] weeklyOSM #420 2018-07-31-2018-08-06

[weeklyteam]

The weekly round-up of OSM news, issue # 420,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10586/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-talk-ie] weeklyOSM #420 2018-07-31-2018-08-06

[weeklyteam]

The weekly round-up of OSM news, issue # 420,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10586/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

[talk-ph] weeklyOSM #420 2018-07-31-2018-08-06

[weeklyteam]

The weekly round-up of OSM news, issue # 420,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10586/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[Talk-GB] weeklyOSM #420 2018-07-31-2018-08-06

[weeklyteam]

The weekly round-up of OSM news, issue # 420,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10586/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-in] weeklyOSM #420 2018-07-31-2018-08-06

[weeklyteam]

The weekly round-up of OSM news, issue # 420,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10586/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[Talk-africa] weeklyOSM #420 2018-07-31-2018-08-06

[weeklyteam]

The weekly round-up of OSM news, issue # 420,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10586/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Mark Wagner]

On Fri, 10 Aug 2018 09:32:50 -0700
Vao Matua  wrote:

> Plus code can be calculated on the fly, but if they are
> to be used we will need to have hardcopy maps with the addresses that
> can be used to direct aid workers to a specific location.

Plus codes form a hierarchical grid, so supporting them on hardcopy
maps can easily be done when the maps are prepared for printing.

I don't know if you're familiar with the UGSG topo maps, but if you
aren't, I recommend looking at one of the 1:24000-scale maps from the
late 1970s/early 1980s.  It's got three location grids on it: UTM
coordinates and latitude/longitude markings on the outside, and PLSS
township/range/section markings on the map itself.  Adding a plus-code
grid to the map would be no problem, and wouldn't require importing
billions of tags into OSM.

-- 
Mark

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Oleksiy Muzalyev]

On 10.08.18 20:46, Christoph Hormann wrote:

On Friday 10 August 2018, Blake Girardot wrote:

[...]

Let us find a local community that is asking for this and give it a
trial there.

I read this as "lets find some country with no sufficiently organized
local community to resists and push this nonsense idea of adding
encoded coordinates as tags to features there in a hope to sneak this
into OSM".  This is exactly the arrogant and abusive approach
what3words used for their proprietary system.

The idea of tagging encoded coordinates is so ridiculous to anyone with
a bit of understanding of computer programming, data processing and
data maintainance that even after ignoring all the arguments in
substance that have been voiced this should be universally rejected if
for no other reason then because it would make OSM the laughing stock
of the whole geodata world.

what3words is a proprietary commercial approach. The OLC is Open Source, 
and it is used at the Google Maps for almost three years.


If OLC generating and search are implemented at the OSM, it would become 
sort of an universal open source standard.


As for using it in tags, if one clicks at another part of the same 
building the OLC code would be different. And what if one wants to have 
a constant legal address?




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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Christoph Hormann]

On Friday 10 August 2018, Blake Girardot wrote:
> [...]
>
> Let us find a local community that is asking for this and give it a
> trial there.

I read this as "lets find some country with no sufficiently organized 
local community to resists and push this nonsense idea of adding 
encoded coordinates as tags to features there in a hope to sneak this 
into OSM".  This is exactly the arrogant and abusive approach 
what3words used for their proprietary system.

The idea of tagging encoded coordinates is so ridiculous to anyone with 
a bit of understanding of computer programming, data processing and 
data maintainance that even after ignoring all the arguments in 
substance that have been voiced this should be universally rejected if 
for no other reason then because it would make OSM the laughing stock 
of the whole geodata world.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Oleksiy Muzalyev]

On 10.08.18 20:09, Martin Koppenhoefer wrote:

this only if you see it as location information, not if it is used as an 
address (the location where to go to, see the example of the long driveway 
above)

Cheers,
Martin
___

There could be a psychological aspect to it too. Up to 40% of some 
cities are constructed without any planning permission meaning that 
theoretically these buildings are "illegal".


These people could not add addr:street= and addr:housenumber= for their 
houses at the OSM map for years, and all of a sudden they can add an 
address. They can have a true modern address, which is probably even 
better than a legacy system offers, which based on the laws of nature.


brgds

O.




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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Barry Hunter]

On Fri, Aug 10, 2018 at 6:09 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 10. Aug 2018, at 19:02, Barry Hunter  wrote:
> >
> > another issue with it being added as tags, if the node is moved to
> correct its location, the editor would have to remember to update the
> plus-code tags as well (not just the lat/long)
>
>
> this only if you see it as location information, not if it is used as an
> address (the location where to go to, see the example of the long driveway
> above)
>

Haven't seen that example.

But in the case of a long driveway wouldnt the address be attached to the
entryway (so that directions etc, can route to the right location)?

The plus-code can be computed from that node.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Blake Girardot]

Friends!

On Fri, Aug 10, 2018 at 12:32 PM, Vao Matua  wrote:
> There are several conflicting perspectives here.
> My objective is to give addresses to people who will never have one.

I want to do this too and plus codes do seem like a good solution, not
perfect, but pretty darn good, especially compared to other options.

But something like this has to be done in conjunction with folks on
the ground who will be affected. OSM has a long history of small scale
trials of tags based on local context.

It also has a history of accepting tags that are sanctioned by
governments or international government organizations (confusingly
enough pcodes for example)

I think an approach based on local buy-in, with a small scale test of
adding the PlusCode address to the objects is the fastest, OSM'ish way
forward.

That will also give those who are interested to add plus codes
programatically to the community developed applications and OSM code
time to do that, if they so choose.

Then we know how well both approaches work for different use cases and
generate some information on if pluscodes are viable solutions or not
to this problem and how best to move forward with them.

Let us find a local community that is asking for this and give it a trial there.

Respectfully,
blake

Last
> year I was living in a city in Africa ( 6GVW2FXH+4H) with a population of a
> half a million people.  None of the streets and roads have names, nor are
> there any house numbers in that city or any of the surrounding rural areas
> where most of the population lives.  As the population in Africa migrates to
> urban settings in the next few decades the cities will be expanding greater
> than governments' ability to create infrastructure, including addresses, to
> support the populations.
> Plus codes is a practical solution to provide addresses that are usable by
> both humans and machines. It is interesting that this effort for addressing
> is being trashed because it is savvy technology.  Plus code can be
> calculated on the fly, but if they are to be used we will need to have
> hardcopy maps with the addresses that can be used to direct aid workers to a
> specific location. Just because something could be done doesn't mean that it
> will or should be done.  If we provide easy access to an address as an
> attribute for OSM it will get used. I don't understand what problems would
> be created by adding valuable information to an address point.  So far I see
> no practical solution for giving an address to the billions of people that
> do not have one, just because a tag value has intelligence and practical
> value is no reason to throw it away.
>
> On Fri, Aug 10, 2018 at 6:05 AM, john whelan  wrote:
>>
>> A simple stopgap solution would be a program that converted one to the
>> other where the result could be cut and pasted into another program.  They
>> are probably called apps these days.
>>
>> If you know the code it would give you the lat and long in a format that
>> could be searched by Nominatim.
>>
>> Grabbing the lat and long from the map and converting it needs a process.
>>
>> Suggestions?
>>
>> Thanks John
>>
>> On Fri, 10 Aug 2018, 8:58 am john whelan,  wrote:
>>>
>>> I would agree the import should be reverted.  The data is redundant and
>>> there is a danger that it might not be correct.  The pure lat and long data
>>> already in OSM can be used to calculate the code.
>>>
>>> It does add weight to the idea of making them searchable perhaps with a
>>> JOSM plugin and support in OSMand for off line use and Nominatim for on line
>>> use.
>>>
>>> Cheerio John
>>>
>>> On Fri, 10 Aug 2018, 8:50 am Michael Reichert, 
>>> wrote:

 Hi,

 Am 2018-08-09 um 22:48 schrieb Vao Matua:
 > The Tanzania Development trust has calculated the Plus Code addresses
 > for
 > 17 million building points in Tanzania and have added a sample village
 > (1800 points) as a test.
 > https://www.openstreetmap.org/changeset/59213224
 >
 > The Python code on Github works great to calculate Plus Codes.
 >
 > We did used these tags:
 > addr:pluscode:full  (the 8+2 digit full Plus Code)
 > addr:pluscode:area (the first 4 digits of the full Plus Code which is
 > a 1
 > degree by 1 degree lat long area)
 > addr:pluscode:local (the second 4 digits + last 2 digits which used
 > with a
 > local name becomes the local address)

 There is no need for this data in OSM because the data can be retrieved
 automatically from latitude and longitude (plain coordinates) which are
 already assigned to anything which has a location on the planet.

 Adding Plus Code tags to OSM objects is as useful as adding latitude=*
 and longitude=* or any other coordinate system which can be calculated
 from latitude and longitude.

 This import should be reverted.

 Best regards

 Michael


 --
 Per E-Mail kommuniziere ich bevorzugt 

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[Paul Johnson]

Sounds fine by me.  Seems there's a decent sized contingency working the
wiki independently of how things are actually tagged anymore, it's been
getting hard to point to the wiki as a usable reference for a couple years
now.

On Fri, Aug 10, 2018, 05:08 Tomasz Wójcik  wrote:

> So basing on your opinions, it looks like highway=* + area=yes isn't
> incorrect, it's just not documented. What do you guys think about adding
> a better documentation of combination with area=yes to some of highway=*
> Wiki pages?
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Martin Koppenhoefer]

sent from a phone

> On 10. Aug 2018, at 19:02, Barry Hunter  wrote:
> 
> another issue with it being added as tags, if the node is moved to correct 
> its location, the editor would have to remember to update the plus-code tags 
> as well (not just the lat/long) 


this only if you see it as location information, not if it is used as an 
address (the location where to go to, see the example of the long driveway 
above)

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Barry Hunter]

> It is interesting that this effort for addressing is being trashed because
> it is savvy technology.
>

Dont see anyone has 'trashed' the idea of using Plus Codes as such.

Just the bulk import of them as *data* to the core OSM database. Its
redundant data.





> Plus code can be calculated on the fly,
>

Exactly, the address search interface/gazetteer could show the address
*with* a plus code.



> but if they are to be used we will need to have hard copy maps with the
> addresses that can be used to direct aid workers to a specific location.
>

So have a fancy renderer than can render the Plus Codes as needed.

Never tried, but it should be possible to render special plus code aligned
grids on the map.


I don't understand what problems would be created by adding valuable
> information to an address point.
>

another issue with it being added as tags, if the node is moved to correct
its location, the editor would have to remember to update the plus-code
tags as well (not just the lat/long)

If want to find where a plus code is, a search interface, can just decode
the plus code, get a lat/long and run a standard geospatial query. That
works *now* worldwide, without any sort of bulk import of tags.

... as tags it would need a text index of the tags, and search that.

Apparently there are currently 4665583767 nodes in OSM, the tags mentioned
seem to be about 83 bytes long. That's 390 *Gigabytes* of data just to add
plus codes to them all.


A basic mobile phone could easily compute the location for a plus-code with
the algorithm. If had to look it up in this database would be way more than
390gb of data on the device! (or need an active internet connection to the
online database)




>   So far I see no practical solution for giving an address to the billions
> of people that do not have one,
>

Every single point on earth already has a plus code already. Its already
been assigned by the algorithm.

Just like every single point as a lat/long coordinate.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Vao Matua]

There are several conflicting perspectives here.
My objective is to give addresses to people who will never have one. Last
year I was living in a city in Africa ( 6GVW2FXH+4H
) with a population
of a half a million people.  None of the streets and roads have names, nor
are there any house numbers in that city or any of the surrounding rural
areas where most of the population lives.  As the population in Africa
migrates to urban settings in the next few decades the cities will be
expanding greater than governments' ability to create infrastructure,
including addresses, to support the populations.
Plus codes is a practical solution to provide addresses that are usable by
both humans and machines. It is interesting that this effort for addressing
is being trashed because it is savvy technology.  Plus code can be
calculated on the fly, but if they are to be used we will need to have
hardcopy maps with the addresses that can be used to direct aid workers to
a specific location. Just because something could be done doesn't mean that
it will or should be done.  If we provide easy access to an address as an
attribute for OSM it will get used. I don't understand what problems would
be created by adding valuable information to an address point.  So far I
see no practical solution for giving an address to the billions of people
that do not have one, just because a tag value has intelligence and
practical value is no reason to throw it away.

On Fri, Aug 10, 2018 at 6:05 AM, john whelan  wrote:

> A simple stopgap solution would be a program that converted one to the
> other where the result could be cut and pasted into another program.  They
> are probably called apps these days.
>
> If you know the code it would give you the lat and long in a format that
> could be searched by Nominatim.
>
> Grabbing the lat and long from the map and converting it needs a process.
>
> Suggestions?
>
> Thanks John
>
> On Fri, 10 Aug 2018, 8:58 am john whelan,  wrote:
>
>> I would agree the import should be reverted.  The data is redundant and
>> there is a danger that it might not be correct.  The pure lat and long data
>> already in OSM can be used to calculate the code.
>>
>> It does add weight to the idea of making them searchable perhaps with a
>> JOSM plugin and support in OSMand for off line use and Nominatim for on
>> line use.
>>
>> Cheerio John
>>
>> On Fri, 10 Aug 2018, 8:50 am Michael Reichert, 
>> wrote:
>>
>>> Hi,
>>>
>>> Am 2018-08-09 um 22:48 schrieb Vao Matua:
>>> > The Tanzania Development trust has calculated the Plus Code addresses
>>> for
>>> > 17 million building points in Tanzania and have added a sample village
>>> > (1800 points) as a test.
>>> > https://www.openstreetmap.org/changeset/59213224
>>> >
>>> > The Python code on Github works great to calculate Plus Codes.
>>> >
>>> > We did used these tags:
>>> > addr:pluscode:full  (the 8+2 digit full Plus Code)
>>> > addr:pluscode:area (the first 4 digits of the full Plus Code which is
>>> a 1
>>> > degree by 1 degree lat long area)
>>> > addr:pluscode:local (the second 4 digits + last 2 digits which used
>>> with a
>>> > local name becomes the local address)
>>>
>>> There is no need for this data in OSM because the data can be retrieved
>>> automatically from latitude and longitude (plain coordinates) which are
>>> already assigned to anything which has a location on the planet.
>>>
>>> Adding Plus Code tags to OSM objects is as useful as adding latitude=*
>>> and longitude=* or any other coordinate system which can be calculated
>>> from latitude and longitude.
>>>
>>> This import should be reverted.
>>>
>>> Best regards
>>>
>>> Michael
>>>
>>>
>>> --
>>> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
>>> ausgenommen)
>>> I prefer GPG encryption of emails. (does not apply on mailing lists)
>>>
>>> ___
>>> talk mailing list
>>> talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk
>>>
>>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[Martin Koppenhoefer]

sent from a phone

> On 10. Aug 2018, at 12:02, Tomasz Wójcik  wrote:
> 
> So basing on your opinions, it looks like highway=* + area=yes isn't 
> incorrect, it's just not documented.


I believe it is documented. It means a traffic area (omnidirectional) as 
opposed to a street (linear). It doesn’t make sense to use highway=secondary 
(for instance) with area=yes, because secondary is a network importance class 
and a traffic area will always have very low importance for the network.


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

Re: [Talk-GB] vehicle barrier

[Martin Wynne]

On 10/08/2018 15:08, Edward Catmur wrote:

Oh, I'd map that as barrier=cycle_barrier without hesitation - it's even
made of the archetypal aluminium tubing.


Ok, will do. It's just that if you asked the residents I don't think 
they intended it primarily to deter furious cycling. Its purpose is 
clearly to prevent through motor traffic.


On the other hand there must have been some reason for the double row of 
railings. But you could stand there all day and not see a cyclist. It's 
a residential area, not on a route from anywhere to anywhere else. And 
there is plenty of room for an occasional cyclist and pedestrians to 
co-exist.


p.s. they are usually galvanised steel, not aluminium.

cheers,

Martin.

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

Re: [Talk-GB] vehicle barrier

[Edward Catmur]

If you don't like barrier=cycle_barrier, there's also barrier=chicane - I'd
consider barrier=cycle_barrier to be a subset of barrier=chicane. But then
you'd definitely need to provide comprehensive access tags.

On Fri, Aug 10, 2018 at 3:08 PM Edward Catmur 
wrote:

>
> Oh, I'd map that as barrier=cycle_barrier without hesitation - it's even
> made of the archetypal aluminium tubing.
>
> The fact that it's across a road rather than a "path, footway, cycleway or
> track" is a pretty minor point compared to construction and intent. For
> prior art see e.g. https://www.openstreetmap.org/node/2512940470 (visible
> on Bing at
> https://www.bing.com/maps?osid=d6b54d2c-03ad-4ada-8b8a-ef341a40ee71=51.498781~-0.092815=19=120.2292=-6.162716=x=z.0=2=2=S00027
> - a bit more ornate, but that's Southwark, and Trinity Church Square is a
> conservation area).
>
> I don't think it matters that pedestrians can bypass it - it still retains
> its principal function of barring motor vehicles (and, presumably, slowing
> down cyclists).
>
> On Fri, Aug 10, 2018 at 1:36 PM Martin Wynne  wrote:
>
>>  > The description of barrier=cycle_barrier in the wiki looks like
>>  > it might be what you need, combined with appropriate access tags.
>>
>>  > I'd say that's a cycle barrier - the intention would be to allow
>>  > pedestrians to pass, force cyclists to dismount
>>
>> Thanks for the suggestions.
>>
>> For cycle_barrier the wiki says "barriers positioned along paths,
>> footways, cycleways or tracks".
>>
>> In this case it is none of those ways, it is a full width road with
>> vehicle access to both sides. But one side is private access and the
>> other is public access (from the other ends).
>>
>> I believe this barrier has been erected by the residents of the private
>> road, rather than the local authority. It's not clear what it achieves
>> which a conventional row of bollards would not.
>>
>> Here's the Google streetview:
>>
>>   https://goo.gl/maps/DGjTum7ynGE2
>>
>> (I haven't mapped it from Google, I actually walked through it
>> yesterday. :) )
>>
>> As you can see, it has been rendered totally ineffective for other than
>> motor vehicles by users pushing past one end. How do we map that?
>>
>> Thanks.
>>
>> Martin.
>>
>>
>>
>> ___
>> 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] 'historic' county boundaries added to the database

[David Woolley]

On 10/08/18 13:00, Martin Wynne wrote:
In this area I was taken to task for adjusting an unexplained boundary, 
which turned out to be the local "PlusBus" area boundary for inclusive 
fares from the nearest railway station


That's likely to be subject to database rights, as I don't think that it 
is normal to sign stops with whether or not they are in the area.


In any case an actual boundary can only be obtained from another map, 
not from the ground.  The best you could do on the ground is identify 
the finite set of existing stops that are in the area.



postal counties


These no longer exist.  All you need to fully address mail is the 
postcode plus the two character delivery point suffix, within that post 
code (which is usually, but not necessarily, a simple encoding of the 
house number, although not in base 10).  In practice, though, the postie 
actually wants the street name as well, as I used just post code and 
house number on the return to sender address, and got a note that it 
takes an extra day to find the street.


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

Re: [Talk-GB] vehicle barrier

[Edward Catmur]

Oh, I'd map that as barrier=cycle_barrier without hesitation - it's even
made of the archetypal aluminium tubing.

The fact that it's across a road rather than a "path, footway, cycleway or
track" is a pretty minor point compared to construction and intent. For
prior art see e.g. https://www.openstreetmap.org/node/2512940470 (visible
on Bing at
https://www.bing.com/maps?osid=d6b54d2c-03ad-4ada-8b8a-ef341a40ee71=51.498781~-0.092815=19=120.2292=-6.162716=x=z.0=2=2=S00027
- a bit more ornate, but that's Southwark, and Trinity Church Square is a
conservation area).

I don't think it matters that pedestrians can bypass it - it still retains
its principal function of barring motor vehicles (and, presumably, slowing
down cyclists).

On Fri, Aug 10, 2018 at 1:36 PM Martin Wynne  wrote:

>  > The description of barrier=cycle_barrier in the wiki looks like
>  > it might be what you need, combined with appropriate access tags.
>
>  > I'd say that's a cycle barrier - the intention would be to allow
>  > pedestrians to pass, force cyclists to dismount
>
> Thanks for the suggestions.
>
> For cycle_barrier the wiki says "barriers positioned along paths,
> footways, cycleways or tracks".
>
> In this case it is none of those ways, it is a full width road with
> vehicle access to both sides. But one side is private access and the
> other is public access (from the other ends).
>
> I believe this barrier has been erected by the residents of the private
> road, rather than the local authority. It's not clear what it achieves
> which a conventional row of bollards would not.
>
> Here's the Google streetview:
>
>   https://goo.gl/maps/DGjTum7ynGE2
>
> (I haven't mapped it from Google, I actually walked through it
> yesterday. :) )
>
> As you can see, it has been rendered totally ineffective for other than
> motor vehicles by users pushing past one end. How do we map that?
>
> Thanks.
>
> Martin.
>
>
>
> ___
> 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] 'historic' county boundaries added to the database

[Colin Smale]

On 2018-08-10 15:35, Mark Goodge wrote:

> On 10/08/2018 13:14, Colin Smale wrote:
> 
>> Who is the arbiter of relevance? I think for any given "mapper" or 
>> "consumer" 99% of the contents of OSM is not relevant. People are mapping 
>> the nuts and bolts of the insulators on electricity pylons.. I can't see 
>> that being relevant to most people.
> 
> Can you see the nuts and bolts?
> 
> I don't think there's any real argument about whether or not we map things we 
> can see. There may be disagreements about *how* we map them, but the basic 
> principle that we map what is visible is, I think, pretty firmly established.
> 
> The basic question here is how we go about mapping things which you can't see 
> - intangibles, such as administrative boundaries, postcodes, road numbers, 
> etc. And that's where questions of relevance come into it.

And by extension the dilemma where what is visible is demonstrably
wrong, e.g. a typo on a street name sign. If we stick to exactly what we
see, we propagate the error. If we apply a bit of QC and make the street
name consistent, we have a better map. 

> The basic principle of OSM is that it is free, in all possible senses. 
> It's free, but it isn't unrestrained. You can't just make up entries. You 
> can't put Ambridge and Hogwarts on the map (although you can, now, include 
> Platform 9 3/4). You can't label a road as a river and a wood as a 
> skyscraper. To be useful, we have to agree to a common set of principles and 
> then stick to them.

Yes you can, until and unless it gets noticed. There are no barriers to
creative, erroneous or downright mischievous tagging - except "social
control" by others, which is very hit-and-miss. In some areas mappers
may have "adopted" their town and monitor every change in a defined
area, and in other cases people might monitor the whole world for a
specific object type. But my suspicion is that most objects in most
places are scarcely "policed" in any way. It would be nice (IMHO) if
this ex-post moderation itself were to be monitored, to help ensure that
every little corner of OSM has somebody/something keeping an eye on it
to detect anomalous mapping, and all the "moderators" (human or
otherwise) worked to consistent standards. But then we get back to the
nub of the problem: who defines these standards, and thereby codifies
what is right and wrong? Nobody wants to burn their fingers on this
proactively, so we are stuck with a patchy, reactive system and the most
incredible inertia which kills many attempts to improve data
consistency. Sacrificing the good on the altar of the perfect...___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSRM-talk] Updating a map

[Sayer, Bryan]

It is possible that your problem is something other than memory, but I have no 
way of knowing.


I believe the usual advice is to use a service like Amazon Web Service (AWS) 
where you can use a machine with more memory for the amount of time it takes to 
prepare the maps. I imagine it would be pretty reasonable in price.


From: Didier Doumerc 
Sent: Friday, August 10, 2018 3:34:42 AM
To: Mailing list to discuss Project OSRM
Subject: Re: [OSRM-talk] Updating a map

I have only 12 GB of RAM but when I installed the previous file version, it was 
ok with only 4 GB or RAM.

Is there anyway way to successfully prepare the files ? Perhaps by downloading 
them ready yet ?

Thanks for your answer.

Didier

Le jeu.09/08/18 à 18:15, Sayer, Bryan a écrit :

When I had that problem it was due to lack of memory. For the United States, I 
had to have 64 GB of memory prepare, though I was doing it through a Stata 
interface, not directly.

From: Didier Doumerc mailto:doumer...@adimep.com>>
Sent: Thursday, August 9, 2018 11:53:39 AM
To: osrm-talk@openstreetmap.org
Subject: [OSRM-talk] Updating a map

Hi,

I need help for updating the map file. Here is what I get when I run 
osrm-prepare france-latest.osrm. It stops at 90%

[info] Input file: france-latest.osrm
[info] Profile: profile.lua
[info] Threads: 8
[info] Loading edge-expanded graph representation
[info] Opening france-latest.osrm.ebg
[info] Reading 25874228 edges from the edge based graph
[info] Done reading edges
[STXXL-MSG] STXXL v1.4.1 (prerelease/Release)
[STXXL-ERRMSG] Warning: no config file found.
[STXXL-ERRMSG] Using default disk configuration.
[STXXL-MSG] Disk '/var/tmp/stxxl' is allocated, space: 1000 MiB, I/O 
implementation: syscall autogrow delete_on_exit queue=0 devid=0
merged 51783408 edges out of 103496912
contractor finished initalization
initializing elimination PQ ...ok
preprocessing 13952773 nodes  10% . 20% . 30% . 40% . 50% . 60% . [flush 
9336408 nodes]  70% . 80% . 90% .



Before, I run osrm-extract france-latest/osm.pbf


[info] Input file: france-latest.osm.pbf
[info] Profile: profile.lua
[info] Threads: 8
[info] Using script profile.lua
[STXXL-MSG] STXXL v1.4.1 (prerelease/Release)
[STXXL-ERRMSG] Warning: no config file found.
[STXXL-ERRMSG] Using default disk configuration.
[STXXL-MSG] Disk '/var/tmp/stxxl' is allocated, space: 1000 MiB, I/O 
implementation: syscall autogrow delete_on_exit queue=0 devid=0
[info] Parsing in progress..
[info] input file generated by osmium/1.8.0
[info] timestamp: 2018-08-05T20:00:03Z
[info] Using turn restrictions
[info] Found 3 exceptions to turn restrictions:
[info]   motorcar
[info]   motor_vehicle
[info]   vehicle
[info] Parsing finished after 914.304 seconds
[info] Raw input contains 387758183 nodes, 57191546 ways, and 521319 relations, 
and 0 unknown entities
[extractor] Sorting used nodes... ok, after 8.97724s
[extractor] Erasing duplicate nodes   ... ok, after 5.16838s
[extractor] Sorting all nodes ... ok, after 270.95s
[extractor] Building node id map  ... ok, after 146.325s
[extractor] setting number of nodes   ... ok
[extractor] Confirming/Writing used nodes ... ok, after 84.6342s
[info] Processed 36442184 nodes
[extractor] Sorting edges by start... ok, after 46.7546s
[extractor] Setting start coords  ... ok, after 188.624s
[extractor] Sorting edges by target   ... ok, after 47.2029s
[extractor] Computing edge weights... ok, after 201.467s
[extractor] Sorting edges by renumbered start ... ok, after 47.6069s
[extractor] Writing used egdes   ... ok, after 33.4863s
[extractor] setting number of edges   ... ok
[info] Processed 37971544 edges
[extractor] Sorting used ways ... ok, after 3.42604s
[extractor] Sorting 34351 restriction. by from... ok, after 0.078667s
[extractor] Fixing restriction starts ... ok, after 1.32651s
[extractor] Sorting restrictions. by to  ... ok, after 0.048604s
[extractor] Fixing restriction ends   ... ok, after 1.28459s
[info] usable restrictions: 31935
[extractor] writing street name index ... ok, after 0.159635s
[info] extraction finished after 2046.13s
[info] Generating edge-expanded graph representation
[info]  - 31935 restrictions.
[info] Importing n = 36442184 nodes
[info]  - 17000 bollard nodes, 41647 traffic lights
[info]  and 37971544 edges
[info] Graph loaded ok and has 37971544 edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Node compression ratio: 0.166043
[info] Edge compression ratio: 0.19941
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 37961020 nodes in edge-expanded graph
[info] generating edge-expanded edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 37961020 edge based nodes
[info] Node-based graph contains 13952773 edges
[info] Edge-expanded graph ...
[info]   contains 25874228 edges
[info]   skips 26910 

Re: [OSM-talk-fr] [OSM-talk] highway=* + area=yes vs area:highway=*

[Philippe Verdy]

highway=* with area=yes are already most often for highway=pedestrian, but
actually renderers already apply consistant representations whe nthese are
used  for other types of highways: the typical use is the representation of
residential highways without exit: instead of a terminal node with a single
highway=turning-circle (which is not very accurate as in most cases the
shapes are pentagonal), the highway is terminated by a  closed
polygon with "highway=residential" + "area=yes".

For now this has no impact on routability there because it is already a
no-exit. But areas still cause problems for routers: for such case we need
to have BOTH a linear representation and the area representation (already
used for plazzas, which also typically have their own name, independantly
of the highway name that crosses it and represented by the linear
representation keeping the name of the street, notably to keep continuity
in addresses with house numbers).

Slowly however, routers and address finders are able to consider areas ;
and note that in some countries or cities (notably in Eastern Asia), house
numbering is made by blocks: blocks are named and represented by surfaces
enclosing several highways, and housenumbers are grouped in that block
independantly of the highway passing through the area.

We are almost ready to have support for both representations (justs like
what was made for rivers with the oriented linear waterway=* and and
non-oriented area-based riverbanks, all of them beoinf groupable in a
relation for the whole river): what is missing is some support in routers
(to determine ways to go): note that we still need the linear
representation at least for one central lane to allow tagging directions
(not possible for tagging restrictions correctly: an area has no well
defined direction even if its shape is a long rubber. using the two
abstractions gives the best of both world and allows compatibilyt with
existing routers which most often ignore areas, and that's why areas are
used most often only for pedestrian areas and no-exit).

However a good question is how to delimit the shape of these streets: only
the areas where vehicle are driving, or including the side parkings, or
including also the footways. detailing of areas by lane seems excessive. In
my opinion, the shape should include the whole street: including parkings
and footways, and separating kerbs or plantations which can be drawn inside
them, but excluding the private areas: it should be limid to barriers,
gates, walls and should not touch the buildings.

Another difficulty existes for bridges: bridges are already representable
(and represented) as shapes with building=bridge, which is convenient to
avoid splitting bridges in two parts when there's a physical central
separation built on top of the bridge. This really helps improving the
rendering of bridges as a single structure, even if on top of it there are
separated unidiretional highways, cycleways, footways, or railways/subway
lines. And note that some bridges also exist on top of buildings and can
pass in the middle of them in a tunnel ! The linear representation only is
difficult to render and interpret on the map but remains useful for routing
algorithms and directional restrictions (and also allows orienting
correctly the labels of street names).

A standard rendering will draw linear highways on top of area-based
highways, making them invisible if the fill colors are identical, provided
that shapes used to render the linear highway do not use any thin borders
to constrast them with the background, but some borders are still drawn
when there steep inclines or protecting walls: these walls should then not
be tagged on the linear highway in that case, but separately on the OSM
ways defining the highway area: this could require using areas represented
by multipolygons, and many people with have difficulties working with them,
so area-based highways will be introduced very slowly, and only in
relatively stable areas which are already densely mapped, to improve the
rendering for high zoom levels and allow easier interpretation. In most
cases, area-based highways are not needed (notably in rural areas, or for
tracks, or for most roads in developping countries where the areas are
unstable across seasons and fuzzily-delimited, and there's actually no need
to represent data with high density of details such as street lights,
signals, bus stop areas, parking lots, recycling containers, details of
footways and crossings, including accessiblity tags for equipments for
walk/vision-handicaped people, and other public equipements on footways
such as benches, water fountains, information panels, and advertizing
panels).

I don't think that OSM should forbid the area representation, but it should
be only a secondary goal, after completing the linear and
oriented representation.


Le ven. 10 août 2018 à 14:22, Jérôme Seigneuret 
a écrit :

> @djakk all object are area but that don't make sens use it in 

Re: [Talk-GB] 'historic' county boundaries added to the database

[Mark Goodge]

On 10/08/2018 13:14, Colin Smale wrote:

Who is the arbiter of relevance? I think for any given "mapper" or 
"consumer" 99% of the contents of OSM is not relevant. People are 
mapping the nuts and bolts of the insulators on electricity pylons.. I 
can't see that being relevant to most people.


Can you see the nuts and bolts?

I don't think there's any real argument about whether or not we map 
things we can see. There may be disagreements about *how* we map them, 
but the basic principle that we map what is visible is, I think, pretty 
firmly established.


The basic question here is how we go about mapping things which you 
can't see - intangibles, such as administrative boundaries, postcodes, 
road numbers, etc. And that's where questions of relevance come into it.


The basic principle of OSM is that it is free, in all possible senses. 


It's free, but it isn't unrestrained. You can't just make up entries. 
You can't put Ambridge and Hogwarts on the map (although you can, now, 
include Platform 9 3/4). You can't label a road as a river and a wood as 
a skyscraper. To be useful, we have to agree to a common set of 
principles and then stick to them.


Mark

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Mike N]

On 8/10/2018 9:01 AM, oleksiy.muzal...@bluewin.ch wrote:
Probably it is done so that plus-codes are known to local actors? 
Perhaps, local conditions differ from European ones to the degree that 
it is difficult to comprehend without being part of local community?


That is a perfect use case for a printed map or app that shows 
plus-codes on buildings or other POIs.  That can be calculated from the 
user's location or location of the POI as the map is being rendered.


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[john whelan]

A simple stopgap solution would be a program that converted one to the
other where the result could be cut and pasted into another program.  They
are probably called apps these days.

If you know the code it would give you the lat and long in a format that
could be searched by Nominatim.

Grabbing the lat and long from the map and converting it needs a process.

Suggestions?

Thanks John

On Fri, 10 Aug 2018, 8:58 am john whelan,  wrote:

> I would agree the import should be reverted.  The data is redundant and
> there is a danger that it might not be correct.  The pure lat and long data
> already in OSM can be used to calculate the code.
>
> It does add weight to the idea of making them searchable perhaps with a
> JOSM plugin and support in OSMand for off line use and Nominatim for on
> line use.
>
> Cheerio John
>
> On Fri, 10 Aug 2018, 8:50 am Michael Reichert, 
> wrote:
>
>> Hi,
>>
>> Am 2018-08-09 um 22:48 schrieb Vao Matua:
>> > The Tanzania Development trust has calculated the Plus Code addresses
>> for
>> > 17 million building points in Tanzania and have added a sample village
>> > (1800 points) as a test.
>> > https://www.openstreetmap.org/changeset/59213224
>> >
>> > The Python code on Github works great to calculate Plus Codes.
>> >
>> > We did used these tags:
>> > addr:pluscode:full  (the 8+2 digit full Plus Code)
>> > addr:pluscode:area (the first 4 digits of the full Plus Code which is a
>> 1
>> > degree by 1 degree lat long area)
>> > addr:pluscode:local (the second 4 digits + last 2 digits which used
>> with a
>> > local name becomes the local address)
>>
>> There is no need for this data in OSM because the data can be retrieved
>> automatically from latitude and longitude (plain coordinates) which are
>> already assigned to anything which has a location on the planet.
>>
>> Adding Plus Code tags to OSM objects is as useful as adding latitude=*
>> and longitude=* or any other coordinate system which can be calculated
>> from latitude and longitude.
>>
>> This import should be reverted.
>>
>> Best regards
>>
>> Michael
>>
>>
>> --
>> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
>> ausgenommen)
>> I prefer GPG encryption of emails. (does not apply on mailing lists)
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[oleksiy.muzal...@bluewin.ch]

Probably it is done so that plus-codes are known to local actors? Perhaps, local conditions differ from European ones to the degree that it is difficult to comprehend without being part of local community?In any case, I actually tried once to pass a location over telephone by telling the coordinates. It was accepted as a joke. No surprise, since there are different formats, negative numbers, etc.Best regards,O.Sent from my Huawei Mobile Original Message Subject: Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?From: Michael Reichert To: Vao Matua CC: openstreetmap Hi,Am 2018-08-09 um 22:48 schrieb Vao Matua:> The Tanzania Development trust has calculated the Plus Code addresses for> 17 million building points in Tanzania and have added a sample village> (1800 points) as a test.> https://www.openstreetmap.org/changeset/59213224> > The Python code on Github works great to calculate Plus Codes.> > We did used these tags:> addr:pluscode:full  (the 8+2 digit full Plus Code)> addr:pluscode:area (the first 4 digits of the full Plus Code which is a 1> degree by 1 degree lat long area)> addr:pluscode:local (the second 4 digits + last 2 digits which used with a> local name becomes the local address)There is no need for this data in OSM because the data can be retrievedautomatically from latitude and longitude (plain coordinates) which arealready assigned to anything which has a location on the planet.Adding Plus Code tags to OSM objects is as useful as adding latitude=*and longitude=* or any other coordinate system which can be calculatedfrom latitude and longitude.This import should be reverted.Best regardsMichael-- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglistenausgenommen)I prefer GPG encryption of emails. (does not apply on mailing lists)___talk mailing listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[john whelan]

I would agree the import should be reverted.  The data is redundant and
there is a danger that it might not be correct.  The pure lat and long data
already in OSM can be used to calculate the code.

It does add weight to the idea of making them searchable perhaps with a
JOSM plugin and support in OSMand for off line use and Nominatim for on
line use.

Cheerio John

On Fri, 10 Aug 2018, 8:50 am Michael Reichert, 
wrote:

> Hi,
>
> Am 2018-08-09 um 22:48 schrieb Vao Matua:
> > The Tanzania Development trust has calculated the Plus Code addresses for
> > 17 million building points in Tanzania and have added a sample village
> > (1800 points) as a test.
> > https://www.openstreetmap.org/changeset/59213224
> >
> > The Python code on Github works great to calculate Plus Codes.
> >
> > We did used these tags:
> > addr:pluscode:full  (the 8+2 digit full Plus Code)
> > addr:pluscode:area (the first 4 digits of the full Plus Code which is a 1
> > degree by 1 degree lat long area)
> > addr:pluscode:local (the second 4 digits + last 2 digits which used with
> a
> > local name becomes the local address)
>
> There is no need for this data in OSM because the data can be retrieved
> automatically from latitude and longitude (plain coordinates) which are
> already assigned to anything which has a location on the planet.
>
> Adding Plus Code tags to OSM objects is as useful as adding latitude=*
> and longitude=* or any other coordinate system which can be calculated
> from latitude and longitude.
>
> This import should be reverted.
>
> Best regards
>
> Michael
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Michael Reichert]

Hi,

Am 2018-08-09 um 22:48 schrieb Vao Matua:
> The Tanzania Development trust has calculated the Plus Code addresses for
> 17 million building points in Tanzania and have added a sample village
> (1800 points) as a test.
> https://www.openstreetmap.org/changeset/59213224
> 
> The Python code on Github works great to calculate Plus Codes.
> 
> We did used these tags:
> addr:pluscode:full  (the 8+2 digit full Plus Code)
> addr:pluscode:area (the first 4 digits of the full Plus Code which is a 1
> degree by 1 degree lat long area)
> addr:pluscode:local (the second 4 digits + last 2 digits which used with a
> local name becomes the local address)

There is no need for this data in OSM because the data can be retrieved
automatically from latitude and longitude (plain coordinates) which are
already assigned to anything which has a location on the planet.

Adding Plus Code tags to OSM objects is as useful as adding latitude=*
and longitude=* or any other coordinate system which can be calculated
from latitude and longitude.

This import should be reverted.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Talk-GB] vehicle barrier

[Martin Wynne]

> The description of barrier=cycle_barrier in the wiki looks like
> it might be what you need, combined with appropriate access tags.

> I'd say that's a cycle barrier - the intention would be to allow
> pedestrians to pass, force cyclists to dismount

Thanks for the suggestions.

For cycle_barrier the wiki says "barriers positioned along paths, 
footways, cycleways or tracks".


In this case it is none of those ways, it is a full width road with 
vehicle access to both sides. But one side is private access and the 
other is public access (from the other ends).


I believe this barrier has been erected by the residents of the private 
road, rather than the local authority. It's not clear what it achieves 
which a conventional row of bollards would not.


Here's the Google streetview:

 https://goo.gl/maps/DGjTum7ynGE2

(I haven't mapped it from Google, I actually walked through it 
yesterday. :) )


As you can see, it has been rendered totally ineffective for other than 
motor vehicles by users pushing past one end. How do we map that?


Thanks.

Martin.



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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Andrew Hain]

Postal counties (mainly a outer London and Manchester thing in this context) 
are essentially defunct.

--
Andrew

From: Martin Wynne 
Sent: 10 August 2018 13:00:40
To: talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] 'historic' county boundaries added to the database

> The "historic" boundaries, though, whatever particular snapshot of them
> you choose as the most important one, don't have any relevance to
> everyday life.

Are not some of them still relevant to post-code areas and postal counties?

Lots of useful stuff appears on OSM for which there is nothing physical
on the ground. Bus stops in rural areas are frequently timetabled as
"Rose & Crown" or the name of a side road. There is nothing on the ground.

In this area I was taken to task for adjusting an unexplained boundary,
which turned out to be the local "PlusBus" area boundary for inclusive
fares from the nearest railway station:

  http://plusbus.info/

Martin.

___
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-ja] placeのcityとtownの使い分け

[tomoya muramoto]

batosm様

ご意見ありがとうございます。
batosm様の感覚のとおり、日本ではplace=city/town/villageは市/町/村と定義されています。詳しくは日本向けの定義をまとめたページをご確認ください。
https://wiki.openstreetmap.org/wiki/Japan_tagging

上記ページを参照すると、千代田区をtownとしたタグ付けは間違いであることが確認できます。

ただ、place=city/town/villageの各ページに日本向けの解説がなかったことも確かなので、この機会に追記いたしました。
https://wiki.openstreetmap.org/wiki/JA:Tag:place%3Dcity
https://wiki.openstreetmap.org/wiki/JA:Tag:place%3Dtown
https://wiki.openstreetmap.org/wiki/JA:Tag:place%3Dvillage

また、iDエディタの翻訳も、「市制地方自治体」といった表記に変えました。

皆様ご意見ください。

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

Re: [OSM-talk-fr] bug de rendu sur les lignes de terrain de sport sur le rendu osmfr

[Philippe Verdy]

Je confirme et c'est partout. Et pas un problème de rafraîchissement ;
certainement un bogue dans la formule de calcul d'angle (ou un changement
inattendu dans une fonction mathématique utilisée)

http://tile.openstreetmap.fr/?zoom=17=48.11792=-1.64677=B00

Si c'était une inversion inattendue des coordonnées x/y ce ne serait pas
une rotation de 90° mais une symétrie par rapport à la diagonale et on
aurait un rendu "presque" correct sur:

http://tile.openstreetmap.fr/?zoom=17=48.11792=-1.64677=B00

où les terrains sont orientés pratiquement sur les diagonales
(contrairement au premier exemple où les terrains sont orientés
pratiquement sur les directions cardinales).


Le ven. 10 août 2018 à 10:32, David Crochet  a
écrit :

> Bonjour
>
> Les rendus des terrains de sport semblent incohérent (rotation de 90° ):
>
>
> http://tile.openstreetmap.fr/?zoom=18=49.17863=-0.37182=B00FF
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OSM-talk] highway=* + area=yes vs area:highway=*

[Jérôme Seigneuret]

@djakk all object are area but that don't make sens use it in database
because data are an abstraction.

area is documented!

highway are in model linestring but in other context it is as an area so
highway area are forced with area=yes to map this object. there is no other
solution to set an highway as a linstring because you can't easily have a
good reprensentation with low level scale and can't map name correctly.
But for micro mapping and set more realistic area (use in zoom level 19, 20
for representation) and data analyse there is an other model and you can
join twice solution. It can be similar to interlis (suisse model)
reprensetion based on data abstraction multilevel. Same data have multiple
object type representation of your information with level scale definition.

database is just a container and store an abstraction of information with a
specific model. You can translate with same model or an other but there is
a limitation corresponding to you abstraction level. an highway is also a
3D reprensation with concrete layers, kerb, and sidewalk...

In other way you separete highway, cycleway, footway and other is there is
a separator but this is the same global 3D object but you need use vector
line and contrains for routing and it can use just in global polygon
object. in this base you need use polygon and line solution.

Other limitation is time cycle, number of contributors, resource
materials and you will do choices to add udpated data in time.

Jerome

Le ven. 10 août 2018 à 13:23, djakk djakk  a écrit :

> No, all highways are areas :) Mapping them as a line is a manual
> generalization ;)
>
>
> djakk
>
>
> Le ven. 10 août 2018 à 12:15, Andy Townsend  a écrit :
>
>>
>> > So basing on your opinions, it looks like highway=* + area=yes isn't
>> incorrect, it's just not documented.
>>
>> I'd suggest that it depends what you're mapping. If it's a predominantly
>> linear feature then it would be wrong to try and "somehow record the width"
>> using area=yes on the highway tag - use area:highway (or width) for that.
>>
>> If it really is an area, then area=yes would make sense.  Most highways
>> are not, though.
>>
>> Best Regards,
>> Andy
>>
>>
>> ___
> talk mailing list
> t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Odp: Re: highway=* + area=yes vs area:highway=*

[Colin Smale]

On 2018-08-10 14:01, marekskleciak wrote:

> We have also mechanism for area routing but, that's true graphs are easier..

Do you have any links/references for area routing? What "mechanism" are
you thinking of here?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] 'historic' county boundaries added to the database

[Colin Smale]

On 2018-08-10 13:37, Mark Goodge wrote:

> On 10/08/2018 12:05, John Aldridge wrote:I'd like to register a +1 in favour 
> of accepting these historic counties.
> 
> I *generally* agree with your principle of 'only mapping what is on the 
> ground', but if we followed that strictly we wouldn't map current 
> administrative boundaries either. These historic counties do, rightly or 
> wrongly, form part of some people's sense of identity *today*, and I think 
> that crosses the bar for inclusion.
> The current administrative boundaries are relevant to everyday life in a 
> number of different ways. Even if you can't see them on the ground, the 
> boundaries determine who collects your bins, who you can vote for, who fixes 
> the potholes in the roads, who manages school admissions, etc.
> 
> The "historic" boundaries, though, whatever particular snapshot of them you 
> choose as the most important one, don't have any relevance to everyday life. 
> They do matter to a small number of people with specialist uses, but - like 
> now-obliterated routes of former railways - they are better suited to a 
> spin-off project rather than being in the core OSM.

Who is the arbiter of relevance? I think for any given "mapper" or
"consumer" 99% of the contents of OSM is not relevant. People are
mapping the nuts and bolts of the insulators on electricity pylons.. I
can't see that being relevant to most people. 

The basic principle of OSM is that it is free, in all possible senses.
There is no up-front right and wrong, nor good and bad; anything goes
unless and until it is noticed and challenged for crossing some
poorly-defined boundary. Often it is the well-intentioned mapper who
opens a discussion prior to adding their favourite information who is
the victim; I expect most mappers just "get on with it" and are never
challenged, however esoteric their mapping. I wish we could be more
consistent in this, but it will probably never happen because of our
collective allergy to limiting mappers' creative freedoms.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] 'historic' county boundaries added to the database

[Dave F]

Hi

On 10/08/2018 12:05, John Aldridge wrote:
I *generally* agree with your principle of 'only mapping what is on 
the ground', but if we followed that strictly we wouldn't map current 
administrative boundaries either. 


That isn't the correct mantra.

"OpenStreetMap is a place for mapping things that are both /real and 
current"/


https://www.openstreetmap.org/welcome

The admin boundaries we map are both real, as set out in legislation, & 
current.


The historic boundaries recently added are not current, their "origins 
lie in antiquity." They are not "used for the purposes of 
administrative, geographical and political demarcation."


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

These historic counties do, rightly or wrongly, form part of some 
people's sense of identity *today*, and I think that crosses the bar 
for inclusion.


But they don't cross OSM's bar.

I'm struggling to fathom how 1888 can be considered "today", and I'm 
unsure how someone's 'sense of identity' is relevant to what is mapped.


'wrongly' is not a reason for inclusion.

Cheers
DaveF



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

[OSM-talk] Odp: Re: highway=* + area=yes vs area:highway=*

[marekskleciak]

We have also mechanism for area routing but, thats true graphs are 
easier..   Dnia 10 sierpnia 2018 13:52 Tom Pfeifer 
t.pfei...@computer.org napisał(a):  On 10.08.2018 13:20, djakk djakk 
wrote:  No, all highways are areas :) Mapping them as a line is a manual 
generalization ;)   1., yes. 2., no, it is a mental abstraction, necessary to 
apply the mathematical graph theory for  routing.   On 10.08.2018 12:02, Tomasz 
Wójcik wrote:   ... it looks like highway=* + area=yes isnt incorrect, 
its just not documented.   As said before, it was documented already on 
the area=* page. It might need to be more explicit on  the highway pages.   tom 
  __  talk mailing list   talk@openstreetmap.org  
lists.openstreetmap.org lists.openstreetmap.org
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] 'historic' county boundaries added to the database

[Martin Wynne]

The "historic" boundaries, though, whatever particular snapshot of them 
you choose as the most important one, don't have any relevance to 
everyday life.


Are not some of them still relevant to post-code areas and postal counties?

Lots of useful stuff appears on OSM for which there is nothing physical 
on the ground. Bus stops in rural areas are frequently timetabled as 
"Rose & Crown" or the name of a side road. There is nothing on the ground.


In this area I was taken to task for adjusting an unexplained boundary, 
which turned out to be the local "PlusBus" area boundary for inclusive 
fares from the nearest railway station:


 http://plusbus.info/

Martin.

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

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[Tom Pfeifer]

On 10.08.2018 13:20, djakk djakk wrote:

No, all highways are areas :) Mapping them as a line is a manual generalization 
;)


1., yes. 2., no, it is a mental abstraction, necessary to apply the mathematical graph theory for 
routing.


On 10.08.2018 12:02, Tomasz Wójcik wrote:
> ... it looks like highway=* + area=yes isn't incorrect, it's just not 
documented.

As said before, it was documented already on the area=* page. It might need to be more explicit on 
the highway pages.


tom

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Mark Goodge]

On 10/08/2018 12:05, John Aldridge wrote:

I'd like to register a +1 in favour of accepting these historic counties.

I *generally* agree with your principle of 'only mapping what is on the 
ground', but if we followed that strictly we wouldn't map current 
administrative boundaries either. These historic counties do, rightly or 
wrongly, form part of some people's sense of identity *today*, and I 
think that crosses the bar for inclusion.


The current administrative boundaries are relevant to everyday life in a 
number of different ways. Even if you can't see them on the ground, the 
boundaries determine who collects your bins, who you can vote for, who 
fixes the potholes in the roads, who manages school admissions, etc.


The "historic" boundaries, though, whatever particular snapshot of them 
you choose as the most important one, don't have any relevance to 
everyday life. They do matter to a small number of people with 
specialist uses, but - like now-obliterated routes of former railways - 
they are better suited to a spin-off project rather than being in the 
core OSM.


Mark

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

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[djakk djakk]

No, all highways are areas :) Mapping them as a line is a manual
generalization ;)


djakk


Le ven. 10 août 2018 à 12:15, Andy Townsend  a écrit :

>
> > So basing on your opinions, it looks like highway=* + area=yes isn't
> incorrect, it's just not documented.
>
> I'd suggest that it depends what you're mapping. If it's a predominantly
> linear feature then it would be wrong to try and "somehow record the width"
> using area=yes on the highway tag - use area:highway (or width) for that.
>
> If it really is an area, then area=yes would make sense.  Most highways
> are not, though.
>
> Best Regards,
> Andy
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-cz] geograficke regiony v CR

[Pavel Machek]

On Fri 2018-08-10 11:19:50, Jan Macura wrote:
> Ahoj,
> 
> nemáte pocit, že tohle do OSM nepatří? Jak se zjišťují hranice a názvy
> geomorfologických jednotek* on the ground*?

Jsem mistni tak to proste vim? Zeptam se mistnich jak se to tady jmenuje? :-).

Ja bych to v mape videl rad.
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-GB] 'historic' county boundaries added to the database

[John Aldridge]

I'd like to register a +1 in favour of accepting these historic counties.

I *generally* agree with your principle of 'only mapping what is on the 
ground', but if we followed that strictly we wouldn't map current 
administrative boundaries either. These historic counties do, rightly or 
wrongly, form part of some people's sense of identity *today*, and I 
think that crosses the bar for inclusion.


--
Cheers,
John

On 10-Aug-18 09:38, Stuart Reynolds wrote:

Hi

I’ve watched this from afar, but thought that I would add my two 
pennyworth, as a more casual mapper.


Historic county boundaries have some merit (in a very general sense), 
but where do you draw the line? As it happens, I was discussing where, 
exactly, Middlesex was with my son only yesterday, and I looked it up on 
Wikipedia. Turns out that Middlesex has changed quite significantly over 
time. First of all, it existed. Then, some of it got plonked into London 
- and it had already lost the City of London and Westminster by then. 
Bits of it got hived off to Hertfordshire. Then the rest of it got 
incorporated into Greater London. So what would you map, historically? 
Do you map every single variation of it, and try and date them all? If 
you were going to map historic counties properly, then you must.


But think what this does to the data. Think what this does for the new 
mapper (who we are trying to encourage). There is now a mass of 
overlapping, conflicting entities to edit. You need to go through every 
one, laboriously, working out which ones you need to edit, and which 
ones you need to leave alone. It’s a data management nightmare, and the 
chances of the wrong thing being edited, or being edited incorrectly, 
rises exponentially.


Personally, I have never particularly liked the variety of ways that OSM 
attempts to map disused / demolished entities (e.g. bus station 
rebuilds, etc) even now. I am firmly of the opinion that we should be 
mapping existing, current, objects, and that things that don’t exist on 
the ground should be ripped out. If OSM as an organisation wants to take 
annual snapshots for posterity, or to set up a separate “historic OSM” 
then I am all for it - I won’t be mapping in it, myself, although I 
would have an interest in using it. As in my Middlesex example, though, 
you would still have data management issues unless you compartmentalise 
it by year - but that is a whole new interface or workflow.


So I am very strongly in favour of NOT mapping historic counties, and 
only mapping what is on the ground (or verifiably shortly to be there, 
as in new builds)


Stuart


On 10 Aug 2018, at 09:24, Sean Blanchflower > wrote:



I guess you at least acknowledge that not everyone agrees with your 
views below though.


A quick factual error though: the traditional/historic counties were 
not administrative in the sense that current areas are. The changes of 
the Local Government Act 1888 were to create administrative areas for 
the first time, and it was the fact that they were called 'counties' 
that has caused all the trouble since then. The government 
acknowledged that the new areas were distinct from the existing 
counties and were not replacing them, and in fact the Ordnance Survey 
continued to print them on maps after then.


How do we reach some compromise here? We seem to be at an impasse.

> I'm sorry, but this is complete and utter bullshit. The "historic" 
> county boundaries are no more "real" than the current ones. They were, 
> at the time, the administrative boundaries. They are no longer the 
> administrative boundaries.

>
> I do appreciate that there are matters where the historic boundaries are 
> relevant (primarily genealogical research). But that's not really a 
> mapping issue., And the emotional attachment to the pre-1974 boundaries 
> is just that - emotion, not based on any objective assessment. And the 
> fact that, in retrospect, the 1970s changes were over-reaching and did a 
> lot of harm does not change that.

>
> Describing the historic boundaries as "real" is like insisting that we 
> map, say, the old Euston station the way it was before it was rebuilt, 
> because it was a lot nicer then. It may well be the case that it was. 
> But we map what exists now, not what existed in the past and in 
> rose-tinted memory. The same with county (and other administrative) 
> boundaries. We map what is, not what was.



On Wed, Aug 8, 2018 at 3:49 PM Sean Blanchflower > wrote:


Hi all,
I'm smb1001 and have been adding the traditional county boundaries
recently. DaveF kindly let me know of the discussion thread here
so I've joined Talk-GB to add my side of things.

I'm not alone in thinking the traditional county boundaries have a
place on current maps. It's unfortunate here that these counties
are known as 'historic counties' as this implies that they are no
longer extant. The debate as to their current 

[Talk-GB] vehicle barrier

[Martin Wynne]

What is the correct tagging for this type of barrier across a road? Two 
lengths of parallel railings with a narrow opening at alternate ends. 
Blocking vehicles but allowing pedestrian access:


___
|___   |


In the particular instance a public road makes an end-on connection with 
a private unadopted road, although both have the same name. It is just 
about possible for pedal bicycles to get through, although I suspect it 
is not intended.


At present I have it has two separate barriers =fence with a short 
length of footpath between them. But clearly it is in fact a single 
construction. And fence suggests a total barrier, so connecting a 
footpath to a fence doesn't make sense.


Thanks,

Martin.

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

Re: [Talk-es] Proyecto de mapeado de info sobre bicicletas

[Patricio Soriano]

Toda la info estará en la wiki de Geoinquietos Córdoba, pero si lo veis
puedo replicar la info en OSM. Este es el enlace de lo que hicimos en 2014 (
https://wiki.osgeo.org/wiki/Opencyclecordoba)

El vie., 10 ago. 2018 a las 12:40, Miguel Sevilla-Callejo (<
msevill...@gmail.com>) escribió:

> Deberíamos poner las iniciativas con los enlaces en la wiki y así tener la
> información centralizada, aún más que por la lista de correo.
>
> Que vaya bien esa iniciativa Patricio. Ya nos dirás
>
> Un saludo
>
> --
> *Miguel Sevilla-Callejo*
> Doctor en Geografía
>
>
> On Fri, 10 Aug 2018 at 12:36, Patricio Soriano 
> wrote:
>
>> Rafa y Miguel muchas gracias a los dos por la contestación.
>>
>> La actividad es muy modesta, pero con la info que me habéis mandado
>> quizás podamos ser un poco más ambiciosos y plantear cierta continuidad.
>> Cuando tenga cartelería y publicidad los pasaré por aquí y lo muevo por
>> las redes.
>>
>>
>>
>> El vie., 10 ago. 2018 a las 10:28, Rafael Oliete Ballester (<
>> raolbale...@gmail.com>) escribió:
>>
>>> Buenos días!
>>>
>>> Miguel muy interesantes los proyectos desde Zaragoza.
>>>
>>> En Valencia hace unos meses se organizó junto con la Concejalía de
>>> Transparencia una actividad de "fotomapeado a nivel de calle"
>>> http://gobiernoabierto.valencia.es/es/20180503-i-mapathon-ciclista-valencia/
>>> Se empleó el servicio Mapillary y fue realmente interesante.
>>> Desde los colectivos ciclistas hubo interés aunque desde el Ayuntamiento
>>> se fue dispersando su interés tras ver que la comunidad que se interesaba
>>> por el tema era pequeña. Una pena.
>>> Desde Geoinquietos Valencia queremos seguir esa línea, es más yo llevo
>>> más de 70km de carriles bici fotomapeados para que luego podamos trabajar
>>> con OSM o mostrar los datos abiertos que comparten desde nuestro
>>> Consistorio.
>>>
>>> La persona que lo gestionó fue Manuel Fernando Benítez de la UJI de
>>> Castellón dentro del proyecto en el que participa de GEO-C
>>> http://geo-c.eu/people#esr
>>>
>>> Un saludo,
>>> Rafael Oliete Ballester
>>>
>>>
>>> On Fri, 10 Aug 2018 at 00:37, Miguel Sevilla-Callejo <
>>> msevill...@gmail.com> wrote:
>>>
 Hola Patricio,

 Disculpa no te haya contestado antes (es lo que tienen las vacaciones),
 en Zaragoza tenemos una "línea" de acción sobre el tema que planteas que
 llamamos #zizlabilidad y del que puedes ver algo en la web del grupo de
 Mapeado Colaborativo: http://mapcolabora.org/project/ziclabilidad/

 Así mismo, hace un año y pico presentamos una comunicación que despues
 publicaron sobre el tema en un congreso sobre la bicicleta que se
 desarrolló en Zaragoza:
 https://github.com/mapcolabora/mapcolabora_material/tree/master/articulos

 No se si es lo que estas buscando exactamente pero quizá te pueda
 interesar nuestra experiencia.

 Ah! por último contarte que andamos por promover un "fotomapeado a
 nivel de calle" de la infraestructura ciclista con colectivos de la
 ciudad... pero esto va un poco lento.

 Ya nos dirás

 Un saludo

 --
 *Miguel Sevilla-Callejo*
 Doctor en Geografía


 On Mon, 23 Jul 2018 at 19:24, Patricio Soriano 
 wrote:

> Buenas tardes,
>
> En la pasada reunión de geoinquietos Córdoba, se no pidió colaboración
> para realizar una actividad dentro de la Semana de la Movilidad
>  que se desarrollará en Septiembre.
>
> En un principio nos propusieron unos paseo en bici para documentar los
> nuevos carriles que se están construyendo, pero desde el grupo lo vimos
> poco operativo y con poco recorrido. Una segunda opción, que parece que es
> la que va a prosperar, es hacer que durante la semana de la actividad y
> con  la etiqueta #mapeomovilidad
>  se vayan
> identificando los elementos vinculados con el tema bici (carriles, señales
> de tráfico, aparcamientos, tiendas...) y al final se realice un taller 
> para
> meter esa información, en el caso que no esté, en OSM.
>
> Todavía está todo un poco en el aire, pero me gustaría saber si
> conocéis experiencias parecidas, otras aspectos vinculados con la bici que
> se puedan documentar, herramientas que podamos usar (ej. estoy 
> investigando
> un script en Python para recuperar los tuis). Hace cuatro años organizamos
> algo parecido y contamos con una base (
> https://wiki.osgeo.org/wiki/Opencyclecordoba
> http://slides.com/patriciosorianocastro/taller-osm-del-i-opencyclecordoba)
>  pero
> cualquier ayuda nos vendría genial.
>
> Muchas gracias de antemano
> --
> Patricio J. Soriano Castro
> *Geógrafo :: Tecnologías de Información Geográfica*
> www.sigdeletras.com :: @SIGdeletras 
>  :: Linkedin 
> 

Re: [Talk-es] Proyecto de mapeado de info sobre bicicletas

[Miguel Sevilla-Callejo]

Deberíamos poner las iniciativas con los enlaces en la wiki y así tener la
información centralizada, aún más que por la lista de correo.

Que vaya bien esa iniciativa Patricio. Ya nos dirás

Un saludo

--
*Miguel Sevilla-Callejo*
Doctor en Geografía


On Fri, 10 Aug 2018 at 12:36, Patricio Soriano  wrote:

> Rafa y Miguel muchas gracias a los dos por la contestación.
>
> La actividad es muy modesta, pero con la info que me habéis mandado quizás
> podamos ser un poco más ambiciosos y plantear cierta continuidad.
> Cuando tenga cartelería y publicidad los pasaré por aquí y lo muevo por
> las redes.
>
>
>
> El vie., 10 ago. 2018 a las 10:28, Rafael Oliete Ballester (<
> raolbale...@gmail.com>) escribió:
>
>> Buenos días!
>>
>> Miguel muy interesantes los proyectos desde Zaragoza.
>>
>> En Valencia hace unos meses se organizó junto con la Concejalía de
>> Transparencia una actividad de "fotomapeado a nivel de calle"
>> http://gobiernoabierto.valencia.es/es/20180503-i-mapathon-ciclista-valencia/
>> Se empleó el servicio Mapillary y fue realmente interesante.
>> Desde los colectivos ciclistas hubo interés aunque desde el Ayuntamiento
>> se fue dispersando su interés tras ver que la comunidad que se interesaba
>> por el tema era pequeña. Una pena.
>> Desde Geoinquietos Valencia queremos seguir esa línea, es más yo llevo
>> más de 70km de carriles bici fotomapeados para que luego podamos trabajar
>> con OSM o mostrar los datos abiertos que comparten desde nuestro
>> Consistorio.
>>
>> La persona que lo gestionó fue Manuel Fernando Benítez de la UJI de
>> Castellón dentro del proyecto en el que participa de GEO-C
>> http://geo-c.eu/people#esr
>>
>> Un saludo,
>> Rafael Oliete Ballester
>>
>>
>> On Fri, 10 Aug 2018 at 00:37, Miguel Sevilla-Callejo <
>> msevill...@gmail.com> wrote:
>>
>>> Hola Patricio,
>>>
>>> Disculpa no te haya contestado antes (es lo que tienen las vacaciones),
>>> en Zaragoza tenemos una "línea" de acción sobre el tema que planteas que
>>> llamamos #zizlabilidad y del que puedes ver algo en la web del grupo de
>>> Mapeado Colaborativo: http://mapcolabora.org/project/ziclabilidad/
>>>
>>> Así mismo, hace un año y pico presentamos una comunicación que despues
>>> publicaron sobre el tema en un congreso sobre la bicicleta que se
>>> desarrolló en Zaragoza:
>>> https://github.com/mapcolabora/mapcolabora_material/tree/master/articulos
>>>
>>> No se si es lo que estas buscando exactamente pero quizá te pueda
>>> interesar nuestra experiencia.
>>>
>>> Ah! por último contarte que andamos por promover un "fotomapeado a nivel
>>> de calle" de la infraestructura ciclista con colectivos de la ciudad...
>>> pero esto va un poco lento.
>>>
>>> Ya nos dirás
>>>
>>> Un saludo
>>>
>>> --
>>> *Miguel Sevilla-Callejo*
>>> Doctor en Geografía
>>>
>>>
>>> On Mon, 23 Jul 2018 at 19:24, Patricio Soriano 
>>> wrote:
>>>
 Buenas tardes,

 En la pasada reunión de geoinquietos Córdoba, se no pidió colaboración
 para realizar una actividad dentro de la Semana de la Movilidad
  que se desarrollará en Septiembre.

 En un principio nos propusieron unos paseo en bici para documentar los
 nuevos carriles que se están construyendo, pero desde el grupo lo vimos
 poco operativo y con poco recorrido. Una segunda opción, que parece que es
 la que va a prosperar, es hacer que durante la semana de la actividad y
 con  la etiqueta #mapeomovilidad
  se vayan
 identificando los elementos vinculados con el tema bici (carriles, señales
 de tráfico, aparcamientos, tiendas...) y al final se realice un taller para
 meter esa información, en el caso que no esté, en OSM.

 Todavía está todo un poco en el aire, pero me gustaría saber si
 conocéis experiencias parecidas, otras aspectos vinculados con la bici que
 se puedan documentar, herramientas que podamos usar (ej. estoy investigando
 un script en Python para recuperar los tuis). Hace cuatro años organizamos
 algo parecido y contamos con una base (
 https://wiki.osgeo.org/wiki/Opencyclecordoba
 http://slides.com/patriciosorianocastro/taller-osm-del-i-opencyclecordoba) 
 pero
 cualquier ayuda nos vendría genial.

 Muchas gracias de antemano
 --
 Patricio J. Soriano Castro
 *Geógrafo :: Tecnologías de Información Geográfica*
 www.sigdeletras.com :: @SIGdeletras 
  :: Linkedin 
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-es

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