[OSM-talk-fr] Cycle de planification stratégique de la OSMF 2023 - Participation de la communauté

[Sarah Hoffmann via Talk-fr]

Hi,

Le conseil d'administration de la Fondation OpenStreetMap révise son plan
stratégique et invite tous les membres de l'OSMF et la communauté OSM à
participer à ce processus.

Le plan est assez détaillé. C'est pourquoi nous voulons en discuter avec vous
en quatre phases au cours des deux prochains mois. Dans chaque phase, nous
nous concentrerons sur un aspect différent du développement stratégique du OSMF.

La première phase est dedié aux "Groupe B : Développement communautaire pour
OSM". Nous vous invitons à nous faire part de vos commentaires pour cette
section au cours des deux prochaines semaines. Vous trouverez toutes les
stratégies de ce cluster dans le page "Groupe B : Développement communautaire
pour l'OSM" à https://wiki.osmfoundation.org/wiki/Cluster_)

Nous aimerions tout particulièrement connaître votre avis sur quatre questions:

* Qu'est-ce qui manque dans le plan ? Ou, autrement dit, que devrions-nous
  ajouter au plan ?
* Y a-t-il des incohérences dans le plan ? Le plan semble-t-il bien aligné
  sur la Déclaration de mission et la direction du mouvement OSM ? Où se
  situent les problèmes ?
* Quelles sont les trois actions les plus urgentes ? Quelles sont les trois
  actions qu'il faut resoudre très bientôt ?
* Quelles sont les trois actions les plus importantes ? Quelles sont les
  actions critiques pour le succès et la croissance d'OpenStreetMap ?

Vous pouvez bien sûr faire des commentaires sur tout autre sujet.

S'il y a un débat sur ce sujet sur l'un des centaines de sites de médias
sociaux qui hébergent des discussions liées à OSM, vous pourriez nous aider
grandement si un membre de ce site ou de ce canal préparait un résumé des
commentaires et le postait (en anglais) à l'équipe. Nous ne pouvons pas
suivre nous-mêmes toutes les discussions sur tous les médias sociaux,
mais nous tenons à entendre vos voix.

Nous suivrons principalement les commentaires à ces deux endroits :

* Le forum général de la communauté OSM sur Discourse
  à https://community.openstreetmap.org/c/general/38/none
* La liste de diffusion de la communauté OSM à laquelle vous pouvez
  accéder en envoyant un courriel à t...@openstreetmap.org.

Je vais aussi avoir un œil sur ce forum francais.

Vous pouvez envoyer des commentaires privés qui ne seront lus que par
l'équipe stratégique à l'adresse strat...@osmfoundation.org ou vous
pouvez écrire individuellement aux membres du conseil d'administration.

En plus, nous vous invitons de discuter avec Sarah en direct l'état présent
et la stratégie future de la OSMF dans un session aux State of the Map 2023
á Marseille. C'est prevu pour Samedi 10 june à 14:30 a la salle Amphi
(voir programme pour changements dernière minute). La session sera en Français.

Merci beaucoup

Sarah Hoffmann, Craig Allan, Allan Mustard

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

Re: [OSM-talk-fr] Mise à jour de Nominatim/Special_phrases/FR

[Sarah Hoffmann via Talk-fr]

On Mon, Jan 23, 2023 at 04:00:03PM +0100, Marc_marc wrote:
> Bonjourr,
> 
> Le 22.01.23 à 20:32, Daniel Garcia a écrit :
> > il faut en discuter quelque part ?
> 
> c'est ce que tu fais ici :)
> ta modification me semble pertinante.
> Mais de mémoire Nominatim ne lit pas cette page fréquement,
> il faudra peut-être ouvrir un ticket pour prise en compte de la modif.

Pas necessaire. Je suis cette liste de diffusion.

Sarah
(admin Nominatim)

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

Re: [OSM-talk-fr] You are an OpenStreetMap Foundation member

[Sarah Hoffmann via Talk-fr]

On Thu, Dec 08, 2022 at 09:56:36AM +0100, Christian Quest wrote:
> Le 07/12/2022 à 21:22, Jacques Lavignotte a écrit :
> > 
> > 
> > Le 07/12/2022 à 20:56, Frédéric Rodrigo a écrit :
> > 
> > >   En
> > > particuliers sur les conflits d'intérêt.
> > 
> > C'est bien à ça que je pense.
> > 
> > J'ai fait comme j'ai pu.
> > 
> > A VOTÉ !
> 
> 
> Pareil, une fois le filtre des conflits d'intérêts passé je n'ai retenu que
> 4 noms, pas un de plus et comme il y a 4 postes à pourvoir, ça tombe bien
> (mais juste).

Petite remarque: avec le système d'élection STV, il est meilleur de
mettre tous les candidats au ballot. Un candidat en fin de liste foncionne
comme un rejet du candidat. Si on ne mets pas le candidat, le vote est
tout simplement perdu.

Sarah

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

Re: [OSM-talk-fr] Accessibilité d'une ville : recommandations

[Sarah Hoffmann via Talk-fr]

On Wed, Dec 07, 2022 at 05:04:20PM +0100, Daniel Garcia wrote:
> Je n'ai jamais vraiment compris la logique de l'algo de Nominatim.
> 
> Je viens de faire un test, avec openstreetmap.org ainsi que via mon
> application OsmAnd.
> 
> Je me suis placé sur une ville du 91, Palaiseau (la gare RER de Palaiseau
> Villebon, pour être plus exact). Ensuite, j'ai cherché "mediatheque" (sans
> accents). Déjà, la carte a sauté vers le premier résultat, donc on n'a
> aucune idée d'où on était avant (ce qui est assez déroutant). Ensuite, on a
> cette liste-ci :
> 
> [image: Screenshot_20221207_164617.png]
> 
> Il y a quand même *beaucoup* de médiathèques plus proches que celle de
> Viry-Chatillon. C'est sans doute le manque d'accents qui le gêne. Les
> résultats sautent vers le 46, puis 78, puis 98, puis 40, puis 98 à
> nouveau... j'ai du mal à croire que la Nouvelle-Calédonie soit plus
> pertinente que les centaines de médiathèques autour de Palaiseau. Sauf
> qu'ils ont ajouté des choses sans accents, et ça suffit pour les faire
> monter dans les résultats.

Rien a voir avec les accents. Les resultats sont simplement les
resultats "exacts". Ca veut dire, les objets OSM ont un tag
'name=Médiathèque' (avec ou sans accents).

La médiathèque la plus proche s'apelle "Médiathèque George Sand".

Cést juste comme explication du algo. Je ne dis pas que c'est parfait comme ca.

Sarah

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

Re: [OSM-talk-fr] Itinéraire vélo non balisé

[Sarah Hoffmann via Talk-fr]

lejun wrote:
> Bonjour,
> 
> Un itinéraire officiel non balisé peut-il d’être renseigné sur
> OpenStreetMap ?
> 
> Le 15 juillet a été officiellement ouvert au public l’itinéraire vélo
> Bio.Velo.Route.[1] par l’équipe d’Anna Deparnay-Grunenberg, députée
> européenne, reliant Strasbourg (France) à Stuttgart (Allemagne).
> L’itinéraire se veut 3.0 en mettant en avant le côté numérique avec
> d’entrée le tracé sous format GPX, sous Komoot et sur uMap – utilisant
> de fait les données OpenStreetMap. J’ai calqué le modèle « Véloroute »
> et j’ai créé une relation pour l’itinéraire[2], sauf qu’on m’a signalé
> l’absence de balisage et que, de fait, ça ne remplirait pas les
> conditions pour figurer sur OpenStreetMap[3]. Des commentaires là
> dessus ? Sans connaître la réalité du terrain – Ni l’envie de me payer
> les 300 bornes sur des voies qui peuvent être mixtes ou non goudronnées
> – ou si un balisage est prévu, j’ai tout de même pour idée que
> l’itinéraire peut figurer dans les données de part son aspect officiel.

Il y a aussi un discussion sur le forum allemand:
https://forum.openstreetmap.org/viewtopic.php?id=76057

L'opinion la est assez unie: c'est la meme chose que un route priveé et
n'a pas une place dans OSM.

Sarah

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

Re: [OSM-talk-fr] Recherche OSM: Nominatim Photon Addok ...

[Sarah Hoffmann via Talk-fr]

On Wed, Apr 27, 2022 at 04:07:22PM +0200, Cyrille37 OSM wrote:
> Bonjour,
> 
> Connaissez-vous des instances utilisables de moteurs de recherche Nominatim
> et autres comme Photon ou Addok ?
> 
> Dans mon panier J'ai seulement :
> - addok : https://demo.addok.xyz
>     - données mises à jour ?
> - photon https://photon.komoot.de
>   - ne répond plus :(

Le demo serveur se trouve sur https://photon.komoot.io depuis quelque temps.

Sarah

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

Re: [Talk-GB] Nominatim oddity

[Sarah Hoffmann]

On Mon, Dec 07, 2020 at 05:42:34PM +, Mark Goodge wrote:
> 
> 
> On 07/12/2020 17:34, Ken Kilfedder wrote:
> > That's the name in latin for the UK, I think.   Is it under name:la,
> > and do you have your browser set to latin for some reason?
> 
> No, my browser is set to English. But it does have Latin as one of several
> alternate languages. Odd that Nominatim seems to be using that rather than
> the browser's preferred language. Maybe it's parsing the language string
> back to front.

Nominatim is missing name:en in its internal list, so name:la is
the next best it finds. Something is wrong with taking over the names
from the OSM country boundaries. I'll have a look.

Sarah

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

Re: [OSM-talk-fr] Élections pour la fondation OSM / l'enjeu de la présence des AFAM ...

[Sarah Hoffmann]

On Sat, Dec 05, 2020 at 08:17:03PM +0100, Christian Quest wrote:
> Le 05/12/2020 à 19:34, Vincent Bergeot a écrit :
> > Le 5 décembre 2020 19:17:59 GMT+01:00, leni  a
> > écrit :
> > 
> > Déjà que lorsque c'est en français, il m'est difficile de pouvoir
> > appréhender ce que chacun des candidats peut apporter, en anglais ... je
> > pense donc que je vais passer mon tour et ne pas voter
> > 
> > bon we
> > 
> > leni
> > 
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> > 
> > 
> > Bonjour,
> > Je comprends cette difficulté (deepl est souvent mon ami). D'où ma
> > demande d'avoir des retours ici, des avis, des impressions pour aider.
> > Je sais que pour ma part j'ai envie de voter pour des candidats qui ne
> > sont pas AFAM... et parmi les autres, complexe ! Un français pour
> > pouvoir causer plus facilement, un hors 'occident' pour diversifier,
> > Roland pour overpass, tobias pour la 'continuité', ...
> > My2cents, mes2sous
> 
> 
> Vu le système de vote, on peut très bien se contenter d'un nom ou deux (ce
> qui en plus renforce le vote pour eux).

Ca dépend. Si il y a un candidat qui tu veux pas du tout avoir dans le board,
il faut forcement mettre tous les autres candidates sur la liste.

Meme chose avec ne pas voter. Le vote perdu est tout a fait un vote pour le
candidate que on prefere pas avoir.

Sarah

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

Re: [OSM-talk-fr] osm.org Affichage ville selon zoom - Vichy vs Cusset

[Sarah Hoffmann]

Salut,

Nominatim se sert de son propre table d'importance qui est computee
au base du comptage liens dans wikipedia. Ca marche assez bien pour
la recherche et j'imagine que ca pourrait marcher aussi bien pour le
rendu.

La table est pre-calculee et peut etre telechargee ici:
https://nominatim.org/data/wikimedia-importance.sql.gz
(c'est une table Postgresql SQL a importer avec:
 zcat wikimedia-importance.sql.gz | psql -d databasename)

Elle contient des valeurs d'importance pour des pages wikipedia
et wikidata. Alors, ca sera facil a ajouter au rendu: un simple
'join' avec le tag wikidata.

Sarah

On Thu, Nov 12, 2020 at 08:57:08AM +0100, Christian Quest wrote:
> Le 11/11/2020 à 22:34, osm.sanspourr...@spamgourmet.com a écrit :
> > Et pour que le rendu osm.org s'en sorte bien, il faut une bonne âme pour
> > faire un PR s'inspirant du travail de Christian.
> > 
> > Christian, tu peux utiliser les relations boundary d'admin_level=8 pour
> > ajouter la population au nœud label ou admin_centre si la population
> > n'est pas donnée.
> > 
> 
> C'est bien trop complexe pour un rendu, car dans les tables générées par
> osm2pgsql ou imposm on n'a pas le détail des relations et des rôles de tel
> ou tel objet.
> 
> On peut sûrement bricoler avec osm2pgsql via les tables qui servent à la
> mise à jour, mais pas avec imposm à ce que je sache et bien sûr ceci a un
> coût en perf (et on sature déjà).
> 
> 
> > Et si tu veux te rappeler si c'est une donnée déduite, tu peux mette un
> > nombre négatif à condition de ne pas oublier de prendre la valeur
> > absolue ;-).
> > 
> > Je dis 8 mais au delà ce serait intéressant pour les villes n'ayant pas
> > capital= : une capitale régionale sera ainsi vue comme plus importante
> > qu'une ville plus peuplée mais simple sous-préfecture par exemple.
> > 
> > Donc peut-être regarder si on a capital= pour savoir si on doit faire
> > "déteindre" la population de la relation sur le nœud. Oui c'est un
> > boulot d'import en plus.
> 
> Pour une amélioration, c'est soit remettre un population=* sur le noeud,
> soit un capital=* (jusqu'à 7 suffit, en France).
> 
> Pour info, dans le wiki :
> 
> - population est en "useful combination" et encourage de le mettre... pas de
> le retirer
> 
> - population n'est même pas mentionné sur boundary=administrative
> 
> 
> -- 
> 
> Christian Quest - OpenStreetMap France
> 
> 
> ___
> 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] Nominatim et plan d'eau

[Sarah Hoffmann]

ne
> bounding-box (deux noeuds sur une diagonale). Et même à la fin quand il
> obtient une liste de résultats filtrés, il ne charge pas la géométrie
> réelle des objets pour vérifier la pertinence réelle.
> 
> Nominatim ne travaille qu'en une seule passe (zéro ou un seul objet, pour
> lui c'est suffisant!) et ne sait pas reprendre son filtrage en réduisant
> ses seuils de pertinence avant les croisements, afin d'obtenir des listes
> d'objets suffisamment peuplées (pas trop) avant de classer par pertinence
> en tenant compte de la géométrie réelle (ce qui peut être couteux et lent
> puisqu'il lui faudrait charger la géométrie complète ces objets, là
> j'admets qu'il doit limiter la longueur de ces listes).
> 
> 
> Le sam. 17 oct. 2020 à 12:18, Sarah Hoffmann  a écrit :
> 
> > On Sat, Oct 17, 2020 at 07:15:22AM +0200, Philippe Verdy wrote:
> > > Si tu enlèves "Saibnt-Jean-de-Braye", Nominatim le trouve.
> > >
> > > Sans doute parce que le plan d'eau est à cheval sur deux communes, et
> > l'est
> > > indexé que sur une seule, sans doute le centroïde.
> > >
> > > Mais si tu cherches sur l'autre commune, Nominatim ne le trouve pas non
> > > plus:
> > >
> > >
> > https://www.openstreetmap.org/search?query=%C3%89tang%20du%20Ruet%2C%20Marigny-les-Usages#map=17/47.94215/2.00436
> > >
> > > Donc une solution possible serait de couper le multipolygone en deux
> > > parties, une pour chaque commune
> >
> > Non! Ca change rien pour Nominatim et ca casse le lac.
> >
> > Si tu veux savoir, ce qui se passe avec la recherche, tu peux te servir de
> > l'interface debug de Nominatim.
> >
> > Va sur https://nominatim.openstreetmap.org/ui/details.html. La on peut
> > entrer soit l'ID de l'objet que tu cherche soit l'URL openstreetmap.
> > Quand il y a un erreur au retour, ca veut dire que Nominatim ne connait
> > pas l'objet.
> >
> > Dans le cas du lac, ca marche et on voit le page du details:
> >
> > https://nominatim.openstreetmap.org/ui/details.html?osmtype=R=2431148=natural
> >
> > Ici, c'est la partie 'Address' qui est le plus interessant. On peut voir
> > ici ou l'objet etait place par Nominatim. Le lac utilise l'adresse de la
> > route D2152. C'est la plus proche du lac, mais malheuresement elle se
> > trouve
> > ni dans Saint-Jean-de-Braye, ni dans Marigny-les-Usages. Cést pour ca que
> > 'Étang du Ruet, Saint-Jean-de-Braye' ne marche pas.
> >
> > Sarah
> >
> > > Le jeu. 15 oct. 2020 à 09:57, Cyrille37 OSM via Talk-fr <
> > > talk-fr@openstreetmap.org> a écrit :
> > >
> > > > Hello,
> > > >
> > > > Nominatim ne trouve pas "Étang du Ruet, Saint-Jean-de-Braye" alors
> > qu'il
> > > > existe bien:
> > > >
> > > >
> > > >
> > https://www.openstreetmap.org/search?query=%C3%89tang%20du%20Ruet%2C%20Saint-Jean-de-Braye#map=17/47.94215/2.00436
> > > >
> > > > Est-ce à cause du natural=water (plan d'eau) ou qu'il s'agit d'une
> > > > relation multi-polygone ?
> > > >
> > > > Merci de vos lumières :-)
> > > > Cyrille37
> > > >
> > > >
> > > > ___
> > > > Talk-fr mailing list
> > > > Talk-fr@openstreetmap.org
> > > > https://lists.openstreetmap.org/listinfo/talk-fr
> > > >
> >
> > > ___
> > > Talk-fr mailing list
> > > Talk-fr@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-fr
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >

> ___
> 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] Nominatim et plan d'eau

[Sarah Hoffmann]

On Sat, Oct 17, 2020 at 07:15:22AM +0200, Philippe Verdy wrote:
> Si tu enlèves "Saibnt-Jean-de-Braye", Nominatim le trouve.
> 
> Sans doute parce que le plan d'eau est à cheval sur deux communes, et l'est
> indexé que sur une seule, sans doute le centroïde.
> 
> Mais si tu cherches sur l'autre commune, Nominatim ne le trouve pas non
> plus:
> 
> https://www.openstreetmap.org/search?query=%C3%89tang%20du%20Ruet%2C%20Marigny-les-Usages#map=17/47.94215/2.00436
> 
> Donc une solution possible serait de couper le multipolygone en deux
> parties, une pour chaque commune

Non! Ca change rien pour Nominatim et ca casse le lac.

Si tu veux savoir, ce qui se passe avec la recherche, tu peux te servir de
l'interface debug de Nominatim.

Va sur https://nominatim.openstreetmap.org/ui/details.html. La on peut
entrer soit l'ID de l'objet que tu cherche soit l'URL openstreetmap.
Quand il y a un erreur au retour, ca veut dire que Nominatim ne connait
pas l'objet.

Dans le cas du lac, ca marche et on voit le page du details:
https://nominatim.openstreetmap.org/ui/details.html?osmtype=R=2431148=natural

Ici, c'est la partie 'Address' qui est le plus interessant. On peut voir
ici ou l'objet etait place par Nominatim. Le lac utilise l'adresse de la
route D2152. C'est la plus proche du lac, mais malheuresement elle se trouve
ni dans Saint-Jean-de-Braye, ni dans Marigny-les-Usages. Cést pour ca que
'Étang du Ruet, Saint-Jean-de-Braye' ne marche pas.

Sarah

> Le jeu. 15 oct. 2020 à 09:57, Cyrille37 OSM via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
> 
> > Hello,
> >
> > Nominatim ne trouve pas "Étang du Ruet, Saint-Jean-de-Braye" alors qu'il
> > existe bien:
> >
> >
> > https://www.openstreetmap.org/search?query=%C3%89tang%20du%20Ruet%2C%20Saint-Jean-de-Braye#map=17/47.94215/2.00436
> >
> > Est-ce à cause du natural=water (plan d'eau) ou qu'il s'agit d'une
> > relation multi-polygone ?
> >
> > Merci de vos lumières :-)
> > Cyrille37
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >

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


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

Re: [OSM-talk] Cannot find address ringvegen 45 Sørkjosen in nominatim

[Sarah Hoffmann]

On Mon, Aug 24, 2020 at 07:28:42AM +0200, Maarten Deen wrote:
> On 2020-08-23 22:20, Sarah Hoffmann wrote:
> > Hi,
> > 
> > On Sun, Aug 23, 2020 at 09:41:10PM +0200, Maarten Deen wrote:
> > > Node 3117603944 was established in 2014 with tags
> > > addr:city Sørkjosen
> > > addr:housenumber  45
> > > addr:postcode 9152
> > > addr:street   Ringvegen
> > > 
> > > Yet, when I query nominatim for Ringvegen 45 Sørkjosen I get no
> > > results.
> > > 
> > > What is going wrong here? Sørkjosen itself is found [2] so the
> > > problem does
> > > not seem to lie in the special character (I wouldn't have thought
> > > so). Also
> > > found is the street which is named Ringveien [3] in OSM. No idea why
> > > the
> > > street is called different than the address node, but does Nominatim
> > > not
> > > index address nodes?
> > 
> > Nominatim only indexes addresses of streets and then searches for
> > address nodes based on the address of the street they are attached
> > to.
> > 
> > In that particular example, the housenumber got attached to Hovedvegen
> > because Nominatim could not find a 'Ringvegen' and used the nearest
> > street:
> > https://nominatim.openstreetmap.org/ui/details.html?osmtype=N=3117603944
> 
> Just one question though (well two acutally): why does it find Hovedvegen as
> nearest street and not Reingveien
> https://nominatim.openstreetmap.org/ui/details.html?osmtype=W=282670088
> ?

Hovedvegen is closer. Nominatim computes distance in WSG84 while you look at a
Mercator map. That far north there is a significant distortion between the two.

> And would it be an idea to make some kind of fuzzy matching when searching
> for names? Like "it is better to take a street which has just one different
> letter then one where all differ"?

This is about consistency between addr:street and names on highways. I think
it is much better to fix the OSM data in this case. Nominatim has always taken
a stance to rather expose mapping issues than trying to work around them.

Sarah

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

Re: [OSM-talk] Cannot find address ringvegen 45 Sørkjosen in nominatim

[Sarah Hoffmann]

On Sun, Aug 23, 2020 at 10:37:48PM +0200, pangoSE wrote:
> Sarah Hoffmann  skrev: (23 augusti 2020 22:20:35 CEST)
> >Nominatim only indexes addresses of streets and then searches for
> >address nodes based on the address of the street they are attached
> >to.
> >
> >In that particular example, the housenumber got attached to Hovedvegen
> >because Nominatim could not find a 'Ringvegen' and used the nearest
> >street:
> >https://nominatim.openstreetmap.org/ui/details.html?osmtype=N=3117603944
> >
> >So you get a slightly different address than expected.
> >Fix the name of the street and everything sorts itself out.
> 
>  thanks for the explanation and link. Are these very useful get parameters 
> documented somewhere? 

https://nominatim.org/release-docs/develop/api/Details/

Use the details page without any paramaters to get a form where
you can select which OSM object to show information about:
https://nominatim.openstreetmap.org/ui/details.html

Sarah

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

Re: [OSM-talk] Cannot find address ringvegen 45 Sørkjosen in nominatim

[Sarah Hoffmann]

Hi,

On Sun, Aug 23, 2020 at 09:41:10PM +0200, Maarten Deen wrote:
> Node 3117603944 was established in 2014 with tags
> addr:city Sørkjosen
> addr:housenumber  45
> addr:postcode 9152
> addr:street   Ringvegen
> 
> Yet, when I query nominatim for Ringvegen 45 Sørkjosen I get no results.
> 
> What is going wrong here? Sørkjosen itself is found [2] so the problem does
> not seem to lie in the special character (I wouldn't have thought so). Also
> found is the street which is named Ringveien [3] in OSM. No idea why the
> street is called different than the address node, but does Nominatim not
> index address nodes?

Nominatim only indexes addresses of streets and then searches for
address nodes based on the address of the street they are attached
to.

In that particular example, the housenumber got attached to Hovedvegen
because Nominatim could not find a 'Ringvegen' and used the nearest
street:
https://nominatim.openstreetmap.org/ui/details.html?osmtype=N=3117603944

So you get a slightly different address than expected.
Fix the name of the street and everything sorts itself out.

Sarah

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

Re: [Talk-GB] Admin Boundaries and Combined Authorities

[Sarah Hoffmann]

Hi,

I'm the one who caused this discussion by editing West Yorkshire. I was looking
into admin boundaries for Nominatim (the search engine) who uses them to
determine the place description or address of a place. As part of this I had
noticed a hole in the admin level 6 coverage and 'fixed' it.

I have to say that this discussion reflects a paradigm shift in the 
interpretation
of boundary=administrative that I find concerning. boundary=administrative used
to reflect the hierarchical structure of a country as viewed by popular use. 
That
is quite practical because it makes it possible to determine reasonable 
subdivisions
from the OSM data without having to know how exactly a country is governed.

Since a few months I notice more and more that people start to interpret
boundary=administrative in a literal sense and argue that all those where there 
is
no direct governmental function have to go away or retagged with something else.
This 'something else' is often locally chosen without any coordination with the
international community or any documentation what so ever (try finding out about
boundary=ceremonial in the wiki if you don't believe me). I fear that we
end up with a fragmentation in tagging that makes it seriously difficult to use 
the
data in a meaningful way.

Coming back to the issue at hand: the regions on admin level 5 may not exactly 
have
an administrative function but my impression is that they are in wide-spread
popular use. I don't visit the UK often but even I am aware of them. That's a
good reason to include them in the boundary=administrative hierarchy. Moving 
them
to some other tagging schema makes them practically invisible.

Mixing regions and CAs in admin_level=5 is not a good idea either because it
breaks the global assumption that the admin_levels create a proper hierarchy.
Same goes for admin_level=5.5. This would be really unexpected and likely just
ignored by most consumers.

Sarah


On Tue, Jul 28, 2020 at 06:41:02AM +0100, Steve Doerr wrote:
> Could they perhaps be 5.5 to distinguish them from regions?
> 
> Steve
> 
> 
> 
> 
> 
> From: Brian Prangle [mailto:bpran...@gmail.com]
> 
> 
> 
> 
> 
> I favour admin  level 5 too.
> 
> 
> 
> On Sun, 26 Jul 2020 at 23:52, Colin Smale   > wrote:
> 
> The LAs of which the CAs are composed are sometimes Metropolitan Boroughs 
> with admin_level=8, and sometimes Unitary Authorities with admin_level=6. I 
> am tending towards admin_level=5; this value is/was in use for the Regions, 
> but they no longer have an admin function (if they ever had one) so I 
> consider admin level 5 as "available" for use by Combined Authorities.
> 
> 
> 
> --
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus

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


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

Re: [OSM-talk] Building a tile-server

[Sarah Hoffmann]

On Wed, Jul 01, 2020 at 03:18:30PM -0500, Tom Browder wrote:
> I am running Debian Buster on a bare-iron dedicated server with 32 Gb
> RAM, 32 cores, and a single 4 TB spinning disk. I am running Pg 12
> (the version maintained by the Pg developers) with its default
> configuration.
> 
> My PostGIS is the latest Debian package version (version ?). osm2pgsql
> is also a package (version ?).
> 
> Should I compile those from source?

Make sure to use osm2pgsql from backports. This always has
the newest released version.

Be aware that you'll likely need osm2pgsql 1.2.2 at the moment
to import a planet. If your import gets stuck when reading
relations then your osm2pgsql is too old.

osm2pgsql 1.2.2 should be available in backports in a couple of
days.

Sarah

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

Re: [OSM-talk] OSM Carto not updating

[Sarah Hoffmann]

Hi,

short update on the issue: libosmium has just made a new release
that fixes the issue: https://github.com/osmcode/libosmium/releases/tag/v2.15.6

osm2pgsql and Nominatim will get new bug-fix releases with the
new libosmium version by today or tomorrow.

You can already download the new libosmium and build osm2pgsql
against that to get a fixed version.

If that is not an option, you can get your installation unstuck for now
by patching the configuration to ignore the offending Klamath forst.

For openstreetmap-carto, add the following patch to your
openstreetmap-carto.lua file:
https://gist.github.com/lonvia/ab7db4156bbfbcf8ebe1ba8185c2e66c

For Nominatim, you need to skip the relation in the import style
file configured through the CONST_Import_Style variable. This
would be settings/import-full.style per default. You need to add
the lines as in this patch:
https://git.openstreetmap.org/nominatim.git/commitdiff/f9ba2af
(careful, the osm.org installation uses import-extratags.style.
 You must apply the patch to the style file you use. Just make
 sure the lines are added at the top of the file.)

In both cases: after you have applied the patch, kill osm2pgsql
and then restart your update process as usual.

Kind regards

Sarah


On Sat, Jun 27, 2020 at 06:25:11PM -0400, Lynn W. Deffenbaugh (Mr) wrote:
> Where is #osm-dev?  I'd like to listen in as my updates are also stalling
> with osm2pgsql ramping up to 100% while processing relations.
> 
> Lynn (D) - Running a planet-wide tile server with updates...  (or trying
> to!)
> 
> On 6/27/2020 11:20 AM, Marc M. wrote:
> > Hello,
> > 
> > Le 27.06.20 à 17:04, ET Commands a écrit :
> > > Is something wrong with the OSM Carto servers?
> > one diff freeze the update
> > sequenceNumber=4082799
> > timestamp=2020-06-26T19:17:02Z
> > ppl on #osm-dev are working on this.
> > 
> > Regards,
> > Marc
> > 
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk] Replication errors

[Sarah Hoffmann]

Hi,

this error has been fixed in the latest release of osmosis.
You need to update your osmosis to a version >= 0.47.2.

Sarah

On Thu, Apr 16, 2020 at 08:10:45AM +0200, Andrzej Kępys wrote:
> Hi All!
> 
> Since few days I have a replication errors using osmosis... Any ideas how to
> fix it? Is there anythink I can do or it's sth about a data?
> 
> ---START
> Thu Apr 16 08:05:01 CEST 2020
> No current.osc file found, downloading new one...
> Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
> INFO: Osmosis Version 0.46
> Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
> INFO: Preparing pipeline.
> Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
> INFO: Launching pipeline execution.
> Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
> INFO: Pipeline executing, waiting for completion.
> Apr 16, 2020 8:05:03 AM 
> org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager 
> waitForCompletion
> SEVERE: Thread for task 1-read-replication-interval failed
> org.openstreetmap.osmosis.core.OsmosisRuntimeException: Unable to parse xml 
> file /tmp/change8964114732320454958.tmp.  publicId=(null), systemId=(null), 
> lineNumber=1775, columnNumber=22.
>   at 
> org.openstreetmap.osmosis.xml.v0_6.XmlChangeReader.run(XmlChangeReader.java:100)
>   at 
> org.openstreetmap.osmosis.replication.v0_6.ReplicationDownloader.processChangeset(ReplicationDownloader.java:107)
>   at 
> org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.processReplicationFile(BaseReplicationDownloader.java:133)
>   at 
> org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.download(BaseReplicationDownloader.java:235)
>   at 
> org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.runImpl(BaseReplicationDownloader.java:271)
>   at 
> org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.run(BaseReplicationDownloader.java:350)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: org.xml.sax.SAXParseException; lineNumber: 1775; columnNumber: 22; 
> Invalid byte 2 of 4-byte UTF-8 sequence.
>   at 
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown 
> Source)
>   at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
>   at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>   at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
>  Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
> Source)
>   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
>   at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
>   at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
> Source)
>   at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
>   at javax.xml.parsers.SAXParser.parse(SAXParser.java:195)
>   at 
> org.openstreetmap.osmosis.xml.v0_6.XmlChangeReader.run(XmlChangeReader.java:90)
>   ... 6 more
> Caused by: org.apache.xerces.impl.io.MalformedByteSequenceException: Invalid 
> byte 2 of 4-byte UTF-8 sequence.
>   at org.apache.xerces.impl.io.UTF8Reader.invalidByte(Unknown Source)
>   at org.apache.xerces.impl.io.UTF8Reader.read(Unknown Source)
>   at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source)
>   at org.apache.xerces.impl.XMLEntityScanner.scanLiteral(Unknown Source)
>   at org.apache.xerces.impl.XMLScanner.scanAttributeValue(Unknown Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanAttribute(Unknown 
> Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
>  Source)
>   ... 16 more
> 
> Apr 16, 2020 8:05:03 AM org.openstreetmap.osmosis.core.Osmosis main
> SEVERE: Execution aborted.
> org.openstreetmap.osmosis.core.OsmosisRuntimeException: One or more tasks 
> failed.
>   at 
> org.openstreetmap.osmosis.core.pipeline.common.Pipeline.waitForCompletion(Pipeline.java:146)
>   at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:92)
>   at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:37)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330)
>   at 
> 

[Talk-es] conoces 'MapCyL'?

[Sarah Hoffmann]

Hi,

perdone por escribir en Ingles. Traducción automática abajo.

You might have noticed that the search function on openstreetmap.org
has not been working very well in the last few weeks. We have battled
with an abusive client that floods the server with bad requests. It
is difficult to find the origin but we have by now narrowed it down
to somebody from Spain. Most likely it is an app that identifies itself
as 'MapCyL'. There is nothing useful to find on Google about it.
Maybe you can help here. Do you have any idea what app may be behind
this user agent? Do you have any idea who we might contact?

Thanks

Sarah
(sysadmin for the Nominatim servers)


Traducción automática:

Es posible que haya notado que la función de búsqueda en openstreetmap.org
no ha funcionado muy bien en las últimas semanas. Hemos luchado
con un cliente abusivo que inunda el servidor con malas busquedas.
Es difícil encontrar el origen pero ya lo hemos restringido
a alguien de España. Lo más probable es que sea una aplicación que se identifica
como 'MapCyL'. No hay nada útil para encontrar en Google al respecto.
Quizás puedas ayudar aquí. ¿Tienes idea de qué aplicación puede estar detrás?
este agente de usuario? ¿Tienes alguna idea de a quién podemos contactar?

Muchas gracias

Sarah

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

[OSM-talk] Call for participation SotM 2020 Cape Town ends Sunday, February 23rd

[Sarah Hoffmann]

Hi all,

just a quick remainder that the call for participation for State of the Map 2020
ends this Sunday, February 23rd.

We are looking forward to your proposals for talks, workshops, panels for
a diverse range of topics around OpenStreetMap.

For more information see: https://2020.stateofthemap.org/cfp/

SotM 2020 once more also has an academic track. The call for papers for
this track is open until March 9th.
More inforation at: https://2020.stateofthemap.org/cfp/academic/

We strive to put together a programe that reflects the diversity of our
community. To help with that, please also forward this remainder to your
local OSM groups. And if you know somebody doing exciting work around
OpenStreetMap, don't hesitate to personally encourage them to propose a
talk, especially when they have not held a talk before.

Kind regards

Sarah

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

[Talk-de] Noch bis Sonntag: Call for Participation SotM Kapstadt 2020

[Sarah Hoffmann]

Hallo,

eine kleine Erinnerung, dass die Einreichefrist für Präsentationen für
die SotM 2020 in Kapstadt an diesem Sonntag, den 23. Februar 2020 endet.

Wir würden uns über zahlreiche Einreichungen freuen!

Mehr Infos: https://2020.stateofthemap.org/cfp/

Für die Wissenschaftler unter euch gibt es auch dieses Jahr wieder einen
akademischen Track. Hier geht die Einreichefrist noch bis zum 9. März.
Infos unter: https://2020.stateofthemap.org/cfp/academic/

Sarah

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

Re: [OSM-talk-fr] extraits et replication sur openstreetmap.fr

[Sarah Hoffmann]

On Sat, Feb 15, 2020 at 10:18:49PM +0100, Jocelyn Jaubert wrote:
> Bonjour,
> 
> Le 15/02/2020 à 18:38, Sarah Hoffmann a écrit :
> > [1] 
> > https://wiki.openstreetmap.org/wiki/PBF_Format#What_are_the_replication_fields_for.3F
> > 
> > Ces champs replication ne sont pas encore disponibles dans les extraits
> > sur openstreetmap.fr. Est ce-que ce sera possible de les ajouter et
> > faire reference au service replication openstreetmap.fr/replication?
> 
> Oui, ça serait une très bonne idée de les ajouter dans les pbf générés.
> 
> J'ai regardé rapidement la documentation, mais je n'ai rien trouvé sur
> comment rajouter ces champs osmosis_replication_sequence_number et
> osmosis_replication_base_url dans le pbf généré. Est-ce que tu saurais
> comment les ajouter ?
> 
> Pour info, les pbf de download.openstreetmap.fr sont simplement mise à
> jour avec osmosis, en récupérant directement les diffs sur la machine,
> et tous les deux jours.
> 
> 
> Et est-ce que c'est possible d'utiliser ces champs avec osmosis pour la
> mise à jour d'un pbf en téléchargeant les bons diffs ?

Je ne crois pas que osmosis ait jamais implemente ca. Vouz pouvez utilise
osmiums tool pour ajouter les champs au fin du proces:

osmium cat -o gibraltar-with-headers.pbf \
--output-header=osmosis_replication_timestamp=2020-01-01T14:16:21Z \
--output-header=osmosis_replication_sequence_number=3456 \

--output-header=http://download.openstreetmap.fr/replication/europe/gibraltar/ 
gibraltar.osm.pbf

Le osmium qui vient avec le distro doit suffire.

Ou, vous pouvez utilises pyosmium-up-to-date pour metre a jour les extraits.
Je viens d'ecrire un peu plus de documentation:
https://github.com/osmcode/pyosmium/blob/master/doc/updating_osm_data.rst#updating-a-planet-or-extract

Sarah

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

[OSM-talk-fr] extraits et replication sur openstreetmap.fr

[Sarah Hoffmann]

Bonjour,

j'ai une petite question pour les admins de openstreetmap.fr.

Je vois que le serveur download.openstreetmap.fr offre non pas
seulement des extraits pbf mais aussi des fichiers 'replication' a la minute.

Depuis quelque temps le format pbf a defini des champs dans le header
pour specifier le 'replication' a utiliser avec le fichier[1]. Ces champs
sont par example utilises par pyosmium-up-to-date, un outil pour mettre
à jour un fichier OSM.

[1] 
https://wiki.openstreetmap.org/wiki/PBF_Format#What_are_the_replication_fields_for.3F

Ces champs replication ne sont pas encore disponibles dans les extraits
sur openstreetmap.fr. Est ce-que ce sera possible de les ajouter et
faire reference au service replication openstreetmap.fr/replication?

Sarah

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

[Talk-de] Vortragseinreichungen für State of the Map 2020 in Kapstadt bis 23. Februar

[Sarah Hoffmann]

Hallo,

die nächste State-of-the-Map-Konferenz wird vom 3.-5. Juli 2020 in
Kapstadt, Südafrika stattfinden. Die SotM ist die internationale
Konferenz der OpenStreetMap-Gemeinschaft.

Bis zum 23. Februar können Vorträge dafür eingereicht werden. Wie jedes Jahr
gibt es verschiedene Tracks von Mapping über Softwareentwicklung bis zu
Community-Themen. Es wird auch wieder einen akademischen Track geben, der
aber noch gesondert angekündigt wird.

Neu dieses Jahr ist der Track 'Art & Creativity'. Er soll die
Gelegenheit bieten, Projekte vorzustellen, wo OpenStreetMap in künstlerischen
Bereichen eingesetzt wird, z.B. Herstellung von Kleidung oder Schmuck, im
3D-Druck, Visualisierungen, als Teil von Spielen, in virtuellen Welten, Postern
oder Postkarten.

Es gibt dieses Jahr auch einen zusätzlichen Vortragstyp: Panel. Diese sind
als Forum gedacht für Diskussionen über brisante, heiss diskutierte Themen
der OSM-Community.

Wir freuen uns schon auf eure Ideen und Vorschläge. Vielleicht kennt ihr
auch Leute, die etwas Interessantes mit OSM machen, aber weniger in der
Community unterwegs ist. Dann macht sie doch auf die SotM aufmerksam.

Mehr Informationen und das Formular zum Einreichen findet ihr unter:

 https://2020.stateofthemap.org/cfp

Für diejenigen, für die eine Reise nach Kapstadt aus finanziellen Gründen
schwierig ist, möchte ich noch hinzufügen, dass es auch dieses Jahr wieder
ein Scholarship-Programm gibt. Neu kann man da auch ein Sponsoring für einen
Teil seiner Reisekosten bekommen. Deadline hier ist der 15. Februar. Mehr
Informationen gibt es auf
https://blog.openstreetmap.org/2020/01/18/sotm2020-applications-for-scholarships-open/

Gruss

Sarah

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

Re: [OSM-talk] osm2pgsql 1.2.0

[Sarah Hoffmann]

Hi,

On Tue, Nov 05, 2019 at 12:16:30AM +0100, wambac...@posteo.de wrote:
> i'm using osm2pgsql-0.96 right now. Is it possible (and meaningful) to
> switch to osm2pgsql-1.2.0?
> 
> Must i change anything in my database? Runing diff updates using a flatfile.

You can switch from 0.96 to 1.2 any time. The database layout
is compatible between the two versions. The only difference is
that 1.x no longer supports old-style multipolygons. That should
not be an issue with the curent planet anyway.

I'd always recommend using the latest release to get the latest fixes.
However, the main performance improvements for 1.2 are noticable during
import. If you prefer a packaged 0.96 over a self-compiled 1.2, then
it's not too much loss to remain with the packages version.

Sarah


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

Re: [OSM-talk] Abuse of natural=cliff tag

[Sarah Hoffmann]

Hi,

On Fri, Sep 06, 2019 at 02:42:06PM +0200, Vladimir Vyskocil wrote:
> Around this area : https://www.openstreetmap.org/#map=16/50.9034/14.2763 
>  there is a flagrant 
> misuse and abuse of the usage of the natural=cliff tag. It is used to map the 
> iso altitude lines and not real cliff as stated in the WIKI :
> 
> A cliff  is a vertical or almost 
> vertical natural drop in terrain topography as it occurs for example in form 
> of coastal cliffs or escarpments. The face of the cliff usually consists of 
> bare solid rock but can occasionally also consist of clay, compacted sand, 
> ice or other solid materials.  

I know that area very well and I can assure you, that natural=cliff is no misuse
under this definition. The area is full of rock towers like those:
https://commons.wikimedia.org/wiki/File:20171124195DR_Lohmen_Basteiaussicht_zum_Sieberturm.jpg

That's what you see on the map.

> I already removed the natural=cliff ways mapped by MichaOSM after asking him 
> to fix this but without response the changeset comment was : 
> 
> "Felsen, Riffe, Topografie nach GeoSachsen digitale Geländemodellhoehenlinien 
> 2.5m, digitales Geländereliefmodell, DTK10, topografische Karte”
> 
> For example this changeset : 
> https://www.openstreetmap.org/changeset/66373825#map=15/50.9016/14.3093 
> 
> 
> It say that it used a 2.5m topographic map to map all these false cliffs in 
> this area, he was mapping the topography (MNT) and this is forbidden in OSM.

You missunderstood, he was mapping rock edges. A terrain model is more helpful
for that task than arial imagery. We have permission to use the terrain model
for OSM as far as I know.

I would kindly request that you reinstate deleted natural=cliffs for
the moment. If you are still not convinced from the photo above that the
tagging is correct then we need to have a fundamental discussion first about
how to tag these kind of rock towers. But that would rather be something for
the tagging mailing list (or talk-de if you want to get the locals involved).

Sarah

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

Re: [OSM-talk-fr] recherche d'une adresse sur Beauvais (Oise)

[Sarah Hoffmann]

On Sun, Aug 11, 2019 at 05:06:10PM +0200, pepilepi...@ovh.fr wrote:
> Le 11/08/2019 à 15:50, Marc Hépiègne a écrit :
> > Bonjour,
> > je fais partie d'une association de promotion des logiciels libres dans
> > l'Oise. Nos activités ont lieu dans un établissement difficile à trouver
> > sur la carte.
> >
> > Il s'agit de l'Ecospace, 136 rue de la Mie au Roy, Beauvais.
> > Si on saisit cette adresse, la carte ne trouve pas.
> > Si on met uniquement l'adresse "136 rue de la Mie au ROY, Beauvais", la
> > carte propose 2 choix qui sont 2 portions de la rue.
> >
> > Une interface comme l'Agenda-du-Libre pointe, elle, sur le milieu d'une
> > des 2 portions qui est un cimetière, exemple :
> > https://www.agendadulibre.org/events/19823
> >
> > En fait, la carte montre bien le lieu si l'utilisateur saisit uniquement
> > "Écospace de la Mie au Roy, Beauvais", sans indication de la rue ni du
> > numéro.
> >
> > L'adresse corrigée par OSM est ensuite :
> > "Parc Écospace de la Mie au Roy, 136, Beauvais, Oise, Hauts-de-France,
> > France métropolitaine, 6, France"
> >
> > Comment faire pour qu'OSM affiche bien le lieu avec l'adresse ordinaire
> > "Ecospace, 136 rue de la Mie au Roy, Beauvais" ce que ferait
> > classiquement un utilisateur lambda ?
> 
> Mettre un point "addr:house number" et le mettre dans une "associated
> street" comme ça . Il
> semblerait qu'OSM n'aime pas voir un numéro de MAISON sur une aire... Du
> moins pour ses recherches. Pourquoi ce comportement ?

Oui, c'est bien ca. Un leisure=park normalement n'a pas une addresse postale.
Les batiments dans le parc, oui, mais pas le parc lui meme.

La relation "associated street" n'est pas necessaire, le point
https://www.openstreetmap.org/node/6700429713 (avec les tags addr:*) suffit.

Sarah

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

Re: [Talk-de] Straßensuche auf openstreetmap.org

[Sarah Hoffmann]

Hallo,

On Sat, Jan 19, 2019 at 08:32:33AM +0100, Martin Trautmann wrote:
> welche bessere Suchmethode empfehlt ihr, als direkt auf
> openstreetmap.org ins Suchfeld den Straßennamen einzugeben?
> 
> Konkret suche ich jede Dorfstraße in der Gemeinde Mansfeld.
> 
> Schafft ihr es, alle zehn (oder mehr) zu finden, dazu noch die vordere,
> hintere, obere und untere?

Für Anfragen der Art "Finde mir alle..." eignet sich Overpass
im Allgemeinen besser. Hier ist, was ich mal auf die schnelle
mit Overpass Turbo zusammenklicken konnte:

https://overpass-turbo.eu/s/FlF

Es gibt bestimmt Experten hier, die das noch besser eingrenzen
können.

Gruss

Sarah

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

Re: [Talk-de] destination_sign Relation auf guidepost auf Flächen zeigen

[Sarah Hoffmann]

Hallo,

On Sun, Oct 07, 2018 at 08:41:37PM +0200, Torbjörn K wrote:
> Hallo zusammen,
> 
> ich bin derzeit dabei in der Nähe befindliche Details zu erweitern und zu 
> ergänzen. Dazu gehören auch Wegweiser von lokalen und regionalen Wanderwegen.
> 
> Dabei habe ich angefangen, die angegebenen Ziele an den Wegweisern mit der 
> "destination_sign"-Relation darzustellen. So wie hier
> 
> Wegweiser: https://www.openstreetmap.org/node/1902038054
> Sieht so aus: https://flic.kr/p/2aGYYDN
> 
> Allerdings bekomme ich ein Problem bei Wegweisern die zu Dinge weisen, die in 
> OSM nicht einzelne Knoten oder Wege, sondern Flächen sind, wie z.B. ein See.

Ich fürchte, du hast das mit dem to-Mitglied noch etwas falsch
verstanden. Dort soll der Weg hinein, auf dem man sich vom
Wanderwegweiser wegbewegen soll, nicht das Ziel, was auf
dem Wegweiser steht. In diesem Fall wäre das also entweder
die Nuss- oder die Frentzenhofstr.

Du kannst dann ausserdem gleichweisende Wegweiser zusammen-
fassen. Hier würden also nur zwei Relationen benötigt.
Eine mit

destination = Brühl;Fischenich;Burg Kendrich
distance = 10.5;1.5;0.3

und eine mit

destination = Köln Sülz;Herrmühlheim;Hürth
distance = ...

> Wegweiser: https://www.openstreetmap.org/node/5032404084
> Sieht so aus: https://flic.kr/p/2aqem46
> Der verwiesene See: https://www.openstreetmap.org/way/
> 144878638#map=16/50.8183/6.8314
> 
> Die destination_sign Relation kann damit nicht umgehen - zumindest nicht laut 
> Wiki und JOSM-Validator.
> 
> Wie gehe ich in solchen Fällen vor?

Da hat der Validatior recht, da er eben eine Strasse oder
einen Knoten auf der Strasse erwartet.

> Oder ist es gar übermäßiger Eifer das alles als Relationen einzutragen?

Nur zu. Du kannst deine Wegweiser seit neustem auch auf waymarkedtrails
anklicken und siehst dort die Relationen:

https://hiking.waymarkedtrails.org/#guidepost?id=1902038054

oder noch etwas ausführlicher von Jan's Seite (wo waymarkedtrails
auch seine Daten herbekommt):

http://osm.mueschelsoft.de/destinationsign/example/index.htm

Auf dieser Seite findest du auch noch mehr Besipiele, wie man die
Relationen am besten mappt.

> Zudem: Ist es empfehlenswert Wegweiser eines bestimmten Wanderweges dessen 
> Relation hinzuzufügen mit der Rolle "guidepost"? Das Wiki sagt "kann man 
> machen" aber ist es auch üblich das zu tun?

Finde ich überflüssig, weil man relativ leicht ermitteln kann, welche
Wegweiser am Rande so einer Wanderroute stehen.

Gruss

Sarah

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

Re: [OSM-talk] Representing places with no housenumber

[Sarah Hoffmann]

On Thu, Aug 23, 2018 at 02:16:02AM -0700, Mark Wagner wrote:
> On Wed, 22 Aug 2018 22:58:07 +0200
> Christoph Hormann  wrote:
> 
> > On Wednesday 22 August 2018, Nelson A. de Oliveira wrote:
> > > > Specifying addr:street on a building that does not have an address
> > > > is either pointless or non-verifiable.  
> > >
> > > But this happens here :-)
> > > Sometimes they are big buildings/areas (which occupies a whole city
> > > block, for example), with addr:street, addr:postcode but no
> > > addr:housenumber  
> > 
> > You probably have to give a real world example since i have no idea
> > if you want to say you have a building with a unique address
> > consisting of addr:street and addr:postcode (could be if there is
> > only one building at this street or with this postcode) or if you
> > want to defend pointless or non-verifiable tagging of addr:street for
> > buildings without a unique address.
> > 
> 
> As a rather extreme first-world example, the address of
> https://www.openstreetmap.org/way/132723167 is:
> 
> name=Grand Canyon North Rim Lodge
> addr:city=North Rim
> addr:state=AZ
> 
> Not only does the building not have a house number, house name, or
> other house identifier, the road it's on isn't named either.  When
> there's only one road in town, and that road only has one building that
> receives mail, you don't need much in the way of identifiers.

This is a rather common case of addressing. Please add addr:place=North Rim to
indicate that this is a street-less address and what is the point of
reference for the address.

Kind regards

Sarah

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

Re: [Talk-de] Relation:boundary

[Sarah Hoffmann]

On Sun, Jul 15, 2018 at 11:01:13PM +0200, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
> > On 15. Jul 2018, at 22:05, Sarah Hoffmann  wrote:
> > 
> > "label" wird wenigstens von Nominatim benutzt. Es hilft dabei
> > herauszufinden, wo sich ein place-Node und eine boundary-Fläche
> > auf das gleiche Objekt beziehen. Und, ja, es wird beides benötigt.
> > Die boundary-Fläche braucht man, um "befindet sich in"-Beziehungen
> > zu ermitteln. Und der Punkt ist nützlich, um den zentralen Punkt
> > des Objektes zu haben.
> 
> 
> dass sowohl ein Punkt als auch eine Fläche Sinn machen bestreite ich nicht, 
> aber wenn „label“ ein Punkt(-member einer Boundaryrelation) ist, und 
> admin_centre auch ein Place-node, wieso braucht Nominatim dann beide bzw. 
> alle drei (einschl. Grenze/Polygon)?

admin_centre wird meistens (aber nicht konsistent) für die Hauptstadt der
jeweiligen administrativen Einheit benutzt. Die Wiki-Beschreibung liest
sich auch eher in diese Richtung ('Sitz der Administration').

Als Beispiel, für Bayern (https://www.openstreetmap.org/relation/2145268) gibt 
es

label:  https://www.openstreetmap.org/node/473848012
admin_centre: https://www.openstreetmap.org/node/1700534808

Gruss

Sarah


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

Re: [Talk-de] Relation:boundary

[Sarah Hoffmann]

On Sun, Jul 15, 2018 at 02:07:10AM +0200, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
> > On 14. Jul 2018, at 14:23, Martin Scholtes  wrote:
> > 
> > Kann mir jemand die  Nutzung von label und admin_centre nochmals erklären?
> > 
> > Label kann man doch die place_node nehmen und bei admin_centre der Sitz
> > der Verwaltung, sozusagen beim Landkreis die Kreisverwaltung.
> 
> 
> „label“ ist keine anerkannte Rolle, 

Das stimmt mal so nicht.

"label" wird wenigstens von Nominatim benutzt. Es hilft dabei
herauszufinden, wo sich ein place-Node und eine boundary-Fläche
auf das gleiche Objekt beziehen. Und, ja, es wird beides benötigt.
Die boundary-Fläche braucht man, um "befindet sich in"-Beziehungen
zu ermitteln. Und der Punkt ist nützlich, um den zentralen Punkt
des Objektes zu haben. Das braucht man spätestens dann, wenn man
bei einem Router einfach einen Stadt-Namen eingeben will und dann
vom Zentrum geroutet werden will und nicht vom grossen Stadtwald,
der sich zufällig am geografischen Mittelpunkt befindet.

> das Beschriften der Daten erledigt der Renderer. Als admin_centre nimmt man 
> das place Objekt (node oder Fläche).

Nur den Node. Ein Place-Flächen-Objekt gehört da nicht rein, sonst
passieren sehr komische Sachen im Renderer.

Gruss

Sarah


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

Re: [OSM-talk] Name:* tags in the local language

[Sarah Hoffmann]

On Tue, Apr 24, 2018 at 08:16:08PM +0200, Frederik Ramm wrote:
> Hi,
> 
> On 04/24/2018 07:23 PM, Paul Norman wrote:
> > If there's agreement that there is a problem here, I could look at
> > preparing a mechanical edit or MapRoulette challenge to add name:* tags,
> > e.g. adding name:en to objects in the US with other name:* tags, and
> > adding name:zh in China. As an estimate, this would be 115k changes in
> > China, touching 28% of roads there.
> 
> Even if there should be agreement that there is a problem here, there
> are other potential solutions.
> 
> Someone once suggested to have a special tag that indicates which name
> tag should be used by default. I.e. we'd have tons of "name:xx" tags
> plus one tag called e.g. "language=en", that would then mean: The
> default name to use is the name:en name.
> 
> I think this would be more elegant than the duplication that you are
> suggesting.

That still doesn't scale. You will have a hard time to convince mappers
to repeatedly add something to objects for which there is an obvious
default. This really should be solved at least partially in software.

I'd like to point to https://wiki.openstreetmap.org/wiki/Nominatim/Country_Codes
again. This list is a good place to start when you want to guess the
language a name tag is in and solves the case for monolingual coutries.
Multilingual countries tend to be more sensitive to the language issue
so that coverage with name:* tags tends to be better.

Also don't mix up the issue of languages and scripts. name:zh is
a point in case where knowing the language doesn't help you if you
want to present the users the map in their favourite script. name:zh
will normally contain Pidgin but may also have traditional Chinese
from time to time.

I strongly recommend to have a look into Sven's work on the German
mapnik style, which has been trying to address a lot of issues with
localized maps: https://github.com/giggls/mapnik-german-l10n

Sarah

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

Re: [OSM-talk] Nominatim on the main page

[Sarah Hoffmann]

On Mon, Feb 19, 2018 at 10:59:31AM +0100, Maarten Deen wrote:
> On 2018-02-19 10:17, Sarah Hoffmann wrote:
> > On Sun, Feb 18, 2018 at 08:12:45PM +0100, Maarten Deen wrote:
> > > On 2018-02-18 20:07, Paul Johnson wrote:
> > > > On Sun, Feb 18, 2018 at 12:53 PM, Maarten Deen <md...@xs4all.nl>
> > > > wrote:
> > > >
> > > > > On 2018-02-18 19:28, Tom Hughes wrote:
> > > 
> > > > > I can't comment about how the algorithm works because I don't know
> > > > > anything about it. I'm just saying that we do tell it the viewbox
> > > >
> > > >  It appears to me that the bounding box is used when searching places
> > > > (towns, cities) or streets, but not when searching objects like shops
> > > > or restaurants.
> > > > For instance, searching for a McDonald's always gives me the
> > > > McDonald's at 1351, George Dieter Drive, El Paso City, El Paso County,
> > > > Texas, 79936, Verenigde Staten van Amerika
> > 
> > To fix that please delete all the wikipedia=McDonalds tags from
> > the McDonalds restaurants that show up inappropriately. Nominatim uses
> > the wikipedia links to determine how well known a place might be and
> > ranks places with a wikipedia tag higher.
> 
> I would expect that a bounding box has precedence over other tags. Why would
> a wikipedia tag have precedence over the bounding box and a name tag not?

It is not a question of precedence. Nominatim looks at different
factors at the same time: the view box, how well-known a place
is (aka wikipedia importance), how well the name of the place matches
your query etc. It takes all these into account weighs them against
each other and comes to a ranking of results.

> But then I still don't understand.
> In the bugreport I have the example of the shop "kruidvat" (it is a chain of
> stores in the Netherlands).
> The bounding box is 6.16575,51.36926,6.17049,51.36759 which centers on the
> Kruidvat store in Venlo [1]. Nominatim returns the kruidvat in Amsterdam
> [2].
> Both nodes have a website tag with the same value. Both nodes have the same
> tags, expect that one has a source tag.
> Then still, why is the boundingbox not looked at _at all_? It's not like
> it's the second or third result, it is the 12th result where all other
> results have similar tags and the results are the same whatever bounding box
> you use.

Interesting. So in this case the importance actually happend to accidentally
cancel out the viewbox influence. I've pushed a preliminary fix to the osm.org
instance. It won't fix the McDonalds or Walmart issues though. They are problems
of a different kind.

Sarah

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

Re: [OSM-talk] Nominatim on the main page

[Sarah Hoffmann]

On Sun, Feb 18, 2018 at 08:15:57PM +, Jorge Gustavo Rocha wrote:
> 
> 
> On 18-02-2018 19:21, Milo van der Linden wrote:
> > With 103 open issues and 12 open pull requests, I would love to
> > volunteer to at least help get those cleared first. Given the (very
> > positive, I am glad so many people are acting on this thread)
> > activity, I think if everybody lends a couple of hours of code this
> > week we can get nominatim ready to make some progress.
> > 
> 
> +1
> 
> I did not blame before, because I never contributed to nominatim. I'll
> take some time this week to review issues and PR (although this week is
> the QGIS hackfest).
> 
> But definitely, I'll use the open data day [1] dedicated to nominatim.
> Maybe we can have a virtual meeting on March 3rd dedicated to nominatim
> to coordinate actions.

Awesome. Nominatim can use all the help it can get.

The open PRs marked 'Changes requested' are an excellent place to start
with. Those are changes that are good in general but unfortunately have
been abandoned by the original author very close before the finish line.

I have also marked a couple of issue as 'simple'. They are good to get
used to the code base before tackling the harder ones.

Kind regards

Sarah

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

Re: [OSM-talk] Nominatim on the main page

[Sarah Hoffmann]

On Sun, Feb 18, 2018 at 08:12:45PM +0100, Maarten Deen wrote:
> On 2018-02-18 20:07, Paul Johnson wrote:
> > On Sun, Feb 18, 2018 at 12:53 PM, Maarten Deen 
> > wrote:
> > 
> > > On 2018-02-18 19:28, Tom Hughes wrote:
> 
> > > I can't comment about how the algorithm works because I don't know
> > > anything about it. I'm just saying that we do tell it the viewbox
> > 
> >  It appears to me that the bounding box is used when searching places
> > (towns, cities) or streets, but not when searching objects like shops
> > or restaurants.
> > For instance, searching for a McDonald's always gives me the
> > McDonald's at 1351, George Dieter Drive, El Paso City, El Paso County,
> > Texas, 79936, Verenigde Staten van Amerika

To fix that please delete all the wikipedia=McDonalds tags from
the McDonalds restaurants that show up inappropriately. Nominatim uses
the wikipedia links to determine how well known a place might be and
ranks places with a wikipedia tag higher. That naturally only works
when the wikipedia tags actually link to a wikipedia page that
describes the object. It leads to funny results when the link goes
to category pages or, like in this case, to the company description.

Alternatively: I've proposed a GSoC to overhaul the Wikipedia
importances that Nominatim uses. Getting rid of this particular
problem from the Nominatim side would be part of this job.

For more information, see:
https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2018/Project_Ideas#Nominatim

There are also two other topics proposed and if you have another particular
itch you want to sratch, there are surely ways they can be transformed into
a GSoC topic. Just send me a email or open an issue in github. It would be 
wonderful, if
we find some students interested in geocoding this year.

Kind regards

Sarah

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

Re: [Talk-de] Tagprioritaet bei OSM-Suche (historic=yes vs. man_made=*)

[Sarah Hoffmann]

On Mon, Jan 08, 2018 at 01:48:47PM +0100, Roland Olbricht wrote:
> Hoi,
> 
> >wenn man in der Kartenansicht auf osm.org mit dem Fragezeichen sucht,
> >dann bekommt man auf der linken Seite eine Trefferliste angezeigt.
> >Keine Ahnung welche Softwarekomponente, die erstellt, jedenfalls wird
> >dort jeweils die Objektnummer und das Haupttag anzeigt, also um was
> >es sich grundsaetzlich handelt. Bei folgender Kombination:
> >
> > man_made=water_well
> > historic=yes
> >
> >wird ``yes'' statt ``water_well'' angezeigt.
> 
> Siehe
> https://github.com/openstreetmap/openstreetmap-website/blob/7fd1e559383807dd0b509c7a08642f9d3a48616e/app/assets/javascripts/index/query.js
> Zeilen 80 bis 112.
> 
> Es wird wahrscheinlich die Konfiguration aus
> https://github.com/openstreetmap/openstreetmap-website/blob/e3357b27e61c3ee4f4cf51c87fdc94deeaaa7c6f/config/locales/de.yml
> verwendet.
> 
> Es gibt dort unter man_made (Zeilen 715 bis 720) keinen Eintrag für
> water_well und auch sonst keine Key-Value-Kombination, die passt. Also wird
> alternativ unter den bekannten Keys für den alphabetisch ersten sein Wert
> direkt übernommen. Der alphabetisch erste ist hier "historic", und das hat
> den Wert "Yes".
> 
> Um das zu beheben, mache also bitte einen Issue auf
> https://github.com/openstreetmap/openstreetmap-website
> auf, dass in die Datei
> openstreetmap/openstreetmap-website/config/locales/de.yml
> der Eintrag "man_made: water_well: Übersetzung auf Deutsch" hinein soll. Den
> wird vermutlich jemand schließen und erklären, auf welchem Weg die
> Übersetzungen in das Repository kommen (war, glaube ich, mal Transifex ?!?).
> Da müsste dann eine Übersetzung für "man_made"="water_well" auf Deutsch
> eingetragen werden.

Die kanonische Key-Value-Definitionen, die als Grundlage für die
Übersetzungen dienen, finden sich in config/locales/en.yml. Gewöhnlich
aktualisiere ich die ab und zu aufgrund der Nutzungshäufigkeiten in
Nominatim. Es ist aber schon eine Weile her, dass ich das das letzte
Mal gemacht habe. Ich schaue mir das mal zeitnah an.

Sobald die Liste aktualisiert ist, kann das dann mit Translatewiki
ins Deutsche übersetzt werden. Ich melde mich dann nochmal.

Gruss

Sarah

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

Re: [Talk-de] Fehler mit Nominatim

[Sarah Hoffmann]

Hallo,

On Sun, Oct 29, 2017 at 12:20:14PM +0100, Scholtes, Martin wrote:
> hab seit einiger Zeit folgenden Fehler:
> 
> Bei der Abfrage einer Örtlichkeit nennt Nominatim mir die Stadt immer mit 
> „Kernstadt“ im Text.
> 
> Als Beispiel: Rettungswache Daun, 8, Auf'm Weiher, Daun (Kernstadt), Daun, 
> Landkreis Vulkaneifel, Rheinland-Pfalz, 54550, Deutschland

Das ist der Stadtteil, den Nominatim hierher nimmt:
http://www.openstreetmap.org/relation/1104029

Du kannst soetwas leicht selber recherchieren, indem
du auf http://nominatim.openstreetmap.org gehst, dort
nach der Örtlichkeit suchst, das gewünschte
Resultat anklickst und dann auf 'Details'.
Dann kommst du auf eine Seite mit allen Details, die
Nominatim zum Suchergebnis hat. Unter anderem finden
sich in der Addressliste Links zu allen OSM-Objekten
die für die Berechnung der Addresse herangezogen
wurden. In der Liste findest du auch "Daun (Kernstadt)".

Sarah

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

Re: [OSM-talk] Fixing OSM wikipedia redirects

[Sarah Hoffmann]

On Tue, Sep 26, 2017 at 04:03:35AM -0400, Yuri Astrakhan wrote:
> Sarah, my understanding is that MapRoulette does not support it -- I cannot
> upload the following:
> 
> For Object ID ,  change one set of tags for another -- accept or
> decline?

No you can't and you shouldn't. Clicking through to two websites and
copying the link is absolutely ok.

> Yes, the community can do it, the question is - should it?  Given 2
> challenges, one that requires some thought, and the other that require
> clicking yes without thinking, shouldn't we opt to the one that computers
> cannot do?  

That's exactly what I'm saying. People don't always want to do the
complicated tasks. There is enough in that in the day job. Sometimes
just clicking through a pile of wikipedia links is totally enough.

Don't just leave the complicated, messy parts of your scripts to the
mappers. It tends to be demotivating because there is no real progress
if you always have to do a lot of research for each single item. And
it is especially demotivating when it is the result of an automated
edit because it feels like spending your time to clean up other people's
mess.

We've just cleaned up hundereds of thousands of polygons through
Maproulette tasks. The popular challenges were the ones which were it
was clear what was to do (not necessarily the same as fixing was easy,
there were complicated multipolygon relations involved), not the ones
where you had to carefully analyse the map to understand what is
going on.

Sarah

> We seemed to assume that donated time is free, unlimited, and
> has very little value. I feel we should treat donated time as the most
> precious and most scarce resource we could get.
> 
> On Tue, Sep 26, 2017 at 3:48 AM, Sarah Hoffmann <lon...@denofr.de> wrote:
> 
> > On Mon, Sep 25, 2017 at 11:53:03PM -0400, Yuri Astrakhan wrote:
> > > According to Martijn (of MapRoulette fame), there is no way a challenge
> > can
> > > link to object IDs. MapRoulette can only highlight location. Nor can I
> > > provide a proposed fix, which means someone would have to manually find
> > the
> > > broken object, navigate to Wikipedia, copy/paste the title, and save the
> > > object.  I guesstimate 1 minute per object on average... that's nearly
> > 700
> > > hours of community time - a huge waste of human brain power that could be
> > > spent on a much more challenging and less automatable tasks.
> >
> > We'd have 40.000 more recently reviewed objects in the database. Given how
> > much the quality of the OSM data decays with time, I would consider that
> > a welcome boost to overall quality.
> >
> > And my experience with the OSM community is that there are a lot of people
> > who wouldn't consider such a task a waste of time but as a wonderful
> > opportunity to relax in the evening. Maproulette has the advantage that
> > you can just click away and do one object after the next. I would recommend
> > to break the 40.000 objects into local batches of 1000 or 2000 and just
> > load it into Maproulette. Add step-by-step isntructions how to fix the
> > links and I'm sure you'll be surprised how quickly everything is done.
> >
> > Kind regards
> >
> > Sarah
> >
> > >
> > > Osmose might be a good alternative, and might even lower the total number
> > > of hours required, but still - would that significantly benefit the
> > > project?  These tags are just a tiny arbitrary subset of one million
> > > wikipedia-tagged objects.  Verifying just them by hand seems like a waste
> > > of human intelligence. Instead, we can run queries to produce knowingly
> > bad
> > > objects and let community fix those. I hope we can let machines do
> > mindless
> > > tasks, and let humans do decision making.  This would improve
> > contributors
> > > morale, instead of making them feel like robots :)
> > >
> > > Clarifying: the OSM objects already point to those pages via redirect.
> > The
> > > redirect information is only stored in Wikipedia.
> > >
> > > On Mon, Sep 25, 2017 at 11:18 PM, Marc Gemis <marc.ge...@gmail.com>
> > wrote:
> > >
> > > > or via Osmose ?
> > > >
> > > > On Tue, Sep 26, 2017 at 5:16 AM, Marc Gemis <marc.ge...@gmail.com>
> > wrote:
> > > > > what about a Maproulette task ?
> > > > >
> > > > > On Tue, Sep 26, 2017 at 5:11 AM, Yuri Astrakhan <
> > yuriastrak...@gmail.com>
> > > > wrote:
> > > > >> At the moment, there are nearly 40,000 OSM objects whose wikipedia
> > tag
> > > > does

Re: [OSM-talk] Fixing OSM wikipedia redirects

[Sarah Hoffmann]

On Mon, Sep 25, 2017 at 11:53:03PM -0400, Yuri Astrakhan wrote:
> According to Martijn (of MapRoulette fame), there is no way a challenge can
> link to object IDs. MapRoulette can only highlight location. Nor can I
> provide a proposed fix, which means someone would have to manually find the
> broken object, navigate to Wikipedia, copy/paste the title, and save the
> object.  I guesstimate 1 minute per object on average... that's nearly 700
> hours of community time - a huge waste of human brain power that could be
> spent on a much more challenging and less automatable tasks.

We'd have 40.000 more recently reviewed objects in the database. Given how
much the quality of the OSM data decays with time, I would consider that
a welcome boost to overall quality.

And my experience with the OSM community is that there are a lot of people
who wouldn't consider such a task a waste of time but as a wonderful
opportunity to relax in the evening. Maproulette has the advantage that
you can just click away and do one object after the next. I would recommend
to break the 40.000 objects into local batches of 1000 or 2000 and just
load it into Maproulette. Add step-by-step isntructions how to fix the
links and I'm sure you'll be surprised how quickly everything is done.

Kind regards

Sarah

> 
> Osmose might be a good alternative, and might even lower the total number
> of hours required, but still - would that significantly benefit the
> project?  These tags are just a tiny arbitrary subset of one million
> wikipedia-tagged objects.  Verifying just them by hand seems like a waste
> of human intelligence. Instead, we can run queries to produce knowingly bad
> objects and let community fix those. I hope we can let machines do mindless
> tasks, and let humans do decision making.  This would improve contributors
> morale, instead of making them feel like robots :)
> 
> Clarifying: the OSM objects already point to those pages via redirect. The
> redirect information is only stored in Wikipedia.
> 
> On Mon, Sep 25, 2017 at 11:18 PM, Marc Gemis  wrote:
> 
> > or via Osmose ?
> >
> > On Tue, Sep 26, 2017 at 5:16 AM, Marc Gemis  wrote:
> > > what about a Maproulette task ?
> > >
> > > On Tue, Sep 26, 2017 at 5:11 AM, Yuri Astrakhan 
> > wrote:
> > >> At the moment, there are nearly 40,000 OSM objects whose wikipedia tag
> > does
> > >> not match their wikidata tag. Most of them are Wikipedia redirects,
> > whose
> > >> target is the right wikipedia article. If we are not ready to abandon
> > >> wikipedia tags just yet (I don't think we should ATM), I think we
> > should fix
> > >> them.  Fixing them by hand seems like a huge waste of the community
> > time,
> > >> when it can be semi-automated.
> > >>
> > >> I propose that a small program, possibly a plugin to JOSM, would change
> > >> wikipedia tags to point to the target article instead of the redirect.
> > >>
> > >> Thoughts?
> > >>
> > >> ___
> > >> talk mailing list
> > >> talk@openstreetmap.org
> > >> https://lists.openstreetmap.org/listinfo/talk
> > >>
> >

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


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

Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

[Sarah Hoffmann]

Hi Frederik,

On Wed, Sep 20, 2017 at 01:56:31AM +0200, Frederik Ramm wrote:
> Hi,
> 
> On 09/19/2017 10:03 PM, Yuri Astrakhan wrote:
> > I would like to auto-add all the
> > corresponding wikidata based on wikipedia, for all remaining objects,
> > using  JOSM's "Fetch Wikidata IDs".
> 
> If the Wikidata ID can be fetched automatically based on the Wikipedia
> tag, can we delete the Wikipedia tags from everything that has Wikidata
> afterwards because it is redundant?

As a reminder: the OSM search engine relies havily on wikipedia tags
to distinguish the important results from the unimportant ones.

If you are interested in keeping a half-way functional search on the
main site, it might be a good idea to find somebody to implement
support for Wikidata IDs in Nominatim before you enagage in a mass deletion
of Wikipedia tags.

Sarah

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

Re: [OSM-talk] OSM Wikidata SPARQL service updated

[Sarah Hoffmann]

On Mon, Aug 21, 2017 at 05:38:06PM -0400, Yuri Astrakhan wrote:
> Sarah, thanks, I created an issue at
> https://github.com/osmcode/pyosmium/issues/47
> 
> Does this mean I cannot even use the existing node cache file when
> processing ways from the minute diff files from pyosmium?

You can do the updates manually as well. Open the node cache file like this:

mapfile = osmium.osm.index.create_map("dense_file_array," + filename)

and hand it into your handler. In the node() callback make sure you
update the locations in the cahce file like this:

   node(self, n):
 if n.deleted:
   mapfile.set(n.id, osmium.osm.Location())
   else:
   mapfile.set(n.id, n.location)

and then change the way callback to simply use the coordinates of a
point in the middle instead of computing a representitive point
from the full way geometry:

  way(self, w):
ndid = w.nodes[len(w.nodes)/2]
point = wkbfab.create_point(mapfile.get(ndid))

That's out of my head, I haven't tested it and you should be adding
a couple of sanity checks for empty ways and points.

Sarah

> 
> On Mon, Aug 21, 2017 at 4:44 PM, Sarah Hoffmann <lon...@denofr.de> wrote:
> 
> > On Sun, Aug 20, 2017 at 11:08:03PM -0400, Yuri Astrakhan wrote:
> > > Sarah, how would I set the node cache file to the repserv.apply_diffs()?
> > > The idx param is passed to the apply_file() - for the initial PBF dump
> > > parsing, but I don't see any place to pass it for the subsequent diff
> > > processing.  I assume there must be a way to run .apply_diff() that will
> > > download the minute diff file, update node cache file with the changed
> > > nodes, and afterwards call my way handler with the updated way
> > geometries.
> >
> > I don't think that is possible yet. For my own projects I have always
> > used an explicit instance of the node cache file and read and written
> > that manually (using the osmium.index.LocationTable() class). But that
> > is not particularly practical. I'll look into adding an idx parameter
> > to the replication mechanism when I find a minute. Feel free to open
> > a feature request on github to remind me.
> >
> > Kind regards
> >
> > Sarah
> >
> > >
> > > Also, I assume you meant dense_file_array, not dense_file_cache. So in my
> > > case I would use one of these idx values when calculating way centroid,
> > and
> > > None otherwise:
> > > sparse_mem_array
> > > dense_mmap_array
> > > sparse_file_array,my_cache_file
> > > dense_file_array,my_cache_file
> > >
> > > Thanks!
> > >
> > >
> > > On Mon, Aug 14, 2017 at 4:31 PM, Sarah Hoffmann <lon...@denofr.de>
> > wrote:
> > >
> > > > On Mon, Aug 14, 2017 at 11:10:39AM -0400, Yuri Astrakhan wrote:
> > > > > mmd, the centroids are calculated with this code, let me know if
> > there
> > > > is a
> > > > > better way, I wasn't aware of any issues with the minute data
> > updates.
> > > > >   wkb = wkbfab.create_linestring(obj)
> > > > >   point = loads(wkb, hex=True).representative_point()
> > > > > https://github.com/nyurik/osm2rdf/blob/master/osm2rdf.py#L250
> > > >
> > > > It doesn't look like you have any location cache included when
> > > > processing updates, so that's unlikely to work.
> > > >
> > > > Minutely updates don't have the full node location information.
> > > > If a way gets updated, you only get the new list of node ids.
> > > > If the nodes have not changed themselves, they are not available
> > > > with the update.
> > > >
> > > > If you need location information, you need to keep a persistent
> > > > node cache in a file (idx=dense_file_cache,file.nodecache)
> > > > and use that in your updates as well. It needs to be updated
> > > > with the fresh node locations from the minutely change files
> > > > and it is used to fill the coordinates for the ways.
> > > >
> > > > Once you have the node cache, you can get the geometries for
> > > > updates ways. This is still only half the truth. If a node in
> > > > a way is moved around, then this will naturally change the
> > > > geometry of the way, but the minutely change file will have
> > > > no indication that the way changed. Normally, these changes are
> > > > relatively small and for some applications it is good enough
> > > > to ignore them (Nominat

Re: [OSM-talk] OSM Wikidata SPARQL service updated

[Sarah Hoffmann]

On Sun, Aug 20, 2017 at 11:08:03PM -0400, Yuri Astrakhan wrote:
> Sarah, how would I set the node cache file to the repserv.apply_diffs()?
> The idx param is passed to the apply_file() - for the initial PBF dump
> parsing, but I don't see any place to pass it for the subsequent diff
> processing.  I assume there must be a way to run .apply_diff() that will
> download the minute diff file, update node cache file with the changed
> nodes, and afterwards call my way handler with the updated way geometries.

I don't think that is possible yet. For my own projects I have always
used an explicit instance of the node cache file and read and written
that manually (using the osmium.index.LocationTable() class). But that
is not particularly practical. I'll look into adding an idx parameter
to the replication mechanism when I find a minute. Feel free to open
a feature request on github to remind me.

Kind regards

Sarah

> 
> Also, I assume you meant dense_file_array, not dense_file_cache. So in my
> case I would use one of these idx values when calculating way centroid, and
> None otherwise:
> sparse_mem_array
> dense_mmap_array
> sparse_file_array,my_cache_file
> dense_file_array,my_cache_file
> 
> Thanks!
> 
> 
> On Mon, Aug 14, 2017 at 4:31 PM, Sarah Hoffmann <lon...@denofr.de> wrote:
> 
> > On Mon, Aug 14, 2017 at 11:10:39AM -0400, Yuri Astrakhan wrote:
> > > mmd, the centroids are calculated with this code, let me know if there
> > is a
> > > better way, I wasn't aware of any issues with the minute data updates.
> > >   wkb = wkbfab.create_linestring(obj)
> > >   point = loads(wkb, hex=True).representative_point()
> > > https://github.com/nyurik/osm2rdf/blob/master/osm2rdf.py#L250
> >
> > It doesn't look like you have any location cache included when
> > processing updates, so that's unlikely to work.
> >
> > Minutely updates don't have the full node location information.
> > If a way gets updated, you only get the new list of node ids.
> > If the nodes have not changed themselves, they are not available
> > with the update.
> >
> > If you need location information, you need to keep a persistent
> > node cache in a file (idx=dense_file_cache,file.nodecache)
> > and use that in your updates as well. It needs to be updated
> > with the fresh node locations from the minutely change files
> > and it is used to fill the coordinates for the ways.
> >
> > Once you have the node cache, you can get the geometries for
> > updates ways. This is still only half the truth. If a node in
> > a way is moved around, then this will naturally change the
> > geometry of the way, but the minutely change file will have
> > no indication that the way changed. Normally, these changes are
> > relatively small and for some applications it is good enough
> > to ignore them (Nominatim, the search engine, does so, for example).
> > If you need to catch that case, then you also need to keep a
> > persistent reverse index of which node is part of which way
> > and for each changed node, update the ways it belongs to.
> > There is currently no support for this in libosmium/pyosmium.
> > So you would need to implement this yourself somehow.
> >
> > Kind regards
> >
> > Sarah
> >
> > >
> > > Your query is correct, and you are right that (in theory) there shouldn't
> > > be any ways without the center point. But there has been a number of ways
> > > with only 1 point, causing a parsing error "need at least two points for
> > > linestring". I will need to add some special handling for that
> > > (suggestions?).
> > >
> > > You can see the error by adding this line:
> > >OPTIONAL { ?osmId osmm:loc:error ?err . }
> > > The whole query --  http://tinyurl.com/ydf4qd62  (you can create short
> > urls
> > > with a button on the left side)
> > >
> > > On Mon, Aug 14, 2017 at 5:18 AM, mmd <mmd@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > Am 13.08.2017 um 19:49 schrieb Yuri Astrakhan:
> > > >
> > > > > * all ways now store "osmm:loc" with centroid coordinates, making it
> > > > > possible to crudely filter ways by location
> > > >
> > > > out of curiosity, can you say a few words on how your overall approach
> > > > to calculate centroids for ways? As we all know it's an endless pain to
> > > > get that information out of minutel

Re: [OSM-talk] OSM Wikidata SPARQL service updated

[Sarah Hoffmann]

On Mon, Aug 14, 2017 at 11:10:39AM -0400, Yuri Astrakhan wrote:
> mmd, the centroids are calculated with this code, let me know if there is a
> better way, I wasn't aware of any issues with the minute data updates.
>   wkb = wkbfab.create_linestring(obj)
>   point = loads(wkb, hex=True).representative_point()
> https://github.com/nyurik/osm2rdf/blob/master/osm2rdf.py#L250

It doesn't look like you have any location cache included when
processing updates, so that's unlikely to work.

Minutely updates don't have the full node location information.
If a way gets updated, you only get the new list of node ids.
If the nodes have not changed themselves, they are not available
with the update.

If you need location information, you need to keep a persistent
node cache in a file (idx=dense_file_cache,file.nodecache)
and use that in your updates as well. It needs to be updated
with the fresh node locations from the minutely change files
and it is used to fill the coordinates for the ways.

Once you have the node cache, you can get the geometries for
updates ways. This is still only half the truth. If a node in
a way is moved around, then this will naturally change the
geometry of the way, but the minutely change file will have
no indication that the way changed. Normally, these changes are
relatively small and for some applications it is good enough
to ignore them (Nominatim, the search engine, does so, for example).
If you need to catch that case, then you also need to keep a
persistent reverse index of which node is part of which way
and for each changed node, update the ways it belongs to.
There is currently no support for this in libosmium/pyosmium.
So you would need to implement this yourself somehow.

Kind regards

Sarah

> 
> Your query is correct, and you are right that (in theory) there shouldn't
> be any ways without the center point. But there has been a number of ways
> with only 1 point, causing a parsing error "need at least two points for
> linestring". I will need to add some special handling for that
> (suggestions?).
> 
> You can see the error by adding this line:
>OPTIONAL { ?osmId osmm:loc:error ?err . }
> The whole query --  http://tinyurl.com/ydf4qd62  (you can create short urls
> with a button on the left side)
> 
> On Mon, Aug 14, 2017 at 5:18 AM, mmd  wrote:
> 
> > Hi,
> >
> > Am 13.08.2017 um 19:49 schrieb Yuri Astrakhan:
> >
> > > * all ways now store "osmm:loc" with centroid coordinates, making it
> > > possible to crudely filter ways by location
> >
> > out of curiosity, can you say a few words on how your overall approach
> > to calculate centroids for ways? As we all know it's an endless pain to
> > get that information out of minutely diffs :)
> >
> > I have to say that I'm pretty much unfamiliar with SPARQL and just tried
> > the following query. My expectation was that I won't get any results,
> > making me wonder if my query has some issue?
> >
> > SELECT * WHERE {
> >   ?osmId osmm:type 'w' .
> >   FILTER NOT EXISTS { ?osmId osmm:loc ?osmLoc }.
> > } LIMIT 100
> >
> >
> > BTW: A quick search on Github yielded the following:
> > https://github.com/nyurik/osm2rdf. Would that be the right place to look
> > for more details?
> >
> > Best,
> > mmd
> >
> >
> > --
> >
> >
> >
> >
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >

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


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

Re: [OSM-talk] new Wikidata+OSM data in one RDF database

[Sarah Hoffmann]

That is quite obviously a bug. For progress on fixing it see
https://github.com/osmcode/pyosmium/issues/38. Please take
into account that the maintainers do sleep from time to time
which might explain why they don't answer immediately. ;)

Kind regards

Sarah

On Thu, May 25, 2017 at 06:54:27AM +, Yuri Astrakhan wrote:
> P.S. I am trying to get OSM updater to work, so that OSM data is always up
> to date, but pyosmium is giving me some trouble. Please email if you know
> the answer to
> https://stackoverflow.com/questions/44170360/callbacks-not-called-in-pyosmiums-diff-downloader
> 
> On Wed, May 24, 2017 at 11:50 PM Yuri Astrakhan 
> wrote:
> 
> > The service is back up, this time with all the objects that have tags.
> > Also, I added the "has" properties on a relation - indicating all objects
> > contained within the relation.  So now you can ask for a relation, that
> > contains a way, and both the relation and the way have the same wikidata ID
> > (something you cannot get from overpass):
> >
> > http://tinyurl.com/k4vjkje
> >
> > "has" could be in one of three forms:
> > ?osmObject1  osmm:has  ?osmObject2   # obj1 contains obj2, no label is set
> > ?osmObject1  osmm:has:inner  ?osmObject2  # can also be outer,
> > center_admin, etc.
> > ?osmObject1  osmm:has:_  ?osmObject2  # the label is not simple ascii,
> > and should be fixed
> >
> >
> > On Mon, May 22, 2017 at 2:04 AM Janko Mihelić  wrote:
> >
> >> Wow, I think this is a great milestone. Thanks!
> >>
> >> Now if only we can get a mixture of Wikidata's SPARQL and Overpass QL. A
> >> kind of a hybrid language between the two? Because Wikidata will probably
> >> never have the Overpass "in" or "around", which narrows the data down to a
> >> single country or county, or to a radius around something. I find that very
> >> useful.
> >>
> >> What if you connected to the Overpass API, ran the Overpass query, and
> >> then filtered the Wikidata data by the results of Overpass? Does that even
> >> make sense? For example: Overpass gives me all elements with a wikidata tag
> >> in a county, and then SPARQL can filter down the data to find all humans
> >> within that data. I think that's possible.
> >>
> >> Anyway, thanks for your service (although I think it's down right now).
> >>
> >> Janko
> >>
> >> ___
> >> talk mailing list
> >> talk@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk
> >>
> >

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


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

Re: [OSM-talk] Nominatim and waterway relations, broken?

[Sarah Hoffmann]

Hi,

On Thu, May 11, 2017 at 11:04:30AM -0700, Ben Discoe wrote:
> Nominatim has been able to find waterway relations for at least a
> couple years, now.
> 
> For example, if you search "Klamath River", Nominatim's top result is:
> https://www.openstreetmap.org/relation/3624126
> 
> Which is great.  But two days ago, I created another river:
> http://www.openstreetmap.org/relation/7232264
> 
> Searching Nominatim for "Spoon River" currently gives "No results found".
> 
> Supposedly, Nominatim's database delay is small (minutes, not days).
> Anyone know why it's failing to find a large, 2-day-old relation?

It's kind of a bug in Nominatim. The relation is there, see
http://nominatim.openstreetmap.org/details.php?osmtype=R=7232264
but search doesn't return it properly.

Feel free to stop reading here, but here are the boring details:

The problem is with the importance of the feature computed from the
wikipedia importance. It is lower than the default importance you
get without a wikipedia tag. Now what happens when you search for
the river is that it looks for the first couple of matching results
ordered by importance and it finds all the ways that make up the
relation (which are also correctly tagged with name=Spoon river)
because they have the higher default importance. Rechecking the
result it realises that all those ways are part of a waterway
relation and shouldn't be returned as separate results. So they
all get deleted again from the result list, leaving an empty list.
The relation you are looking for never makes it out of the database.
You can get it, if you ask for more results:
http://nominatim.openstreetmap.org/?q=spoon%20river=50

The proper fix is to remove the ways that make up the relation
from the search index. I'm not sure how simple that actually is. I'll
look into it. Progress can be tracked in
https://github.com/openstreetmap/Nominatim/issues/722

Kind regards

Sarah

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

Re: [OSM-talk] Looking for "primary language" map

[Sarah Hoffmann]

On Tue, Apr 11, 2017 at 01:06:39AM +, Yuri Astrakhan wrote:
> I simply need to determine the most likely language of the "name" tag (not
> the "name:xx" tag). Does not have to be 100% correct - even 80% is great.

Nominatim uses https://wiki.openstreetmap.org/wiki/Nominatim/Country_Codes
on a per country base. For multi-lingual display, this is generally
a good enough heuristics because

a) smaller places only have a name tag, so language is not relevant, you
   simply display the single name available

b) countries with more than one official language are mostly aware
   of the issue and have the appropriate name:xx tag set in addition
 to the name tag. So just usename:xx directly or determine the
 language of the name tag by comparing with the name:xx tags

So you basically only need to really know the language for strictly
monolingual regions. (Nominatim currently ignores all lines in that
table where there is more than one langauge.)

The problem becomes a bit more interesting when you are looking for
appropriate fallback languages because then generally script comes
into play.

Sarah


> 
> On Mon, Apr 10, 2017 at 8:59 PM john whelan  wrote:
> 
> Orleans is part of Ottawa and all street names signs are bilingual or in
> the process of being replaced by bilingual ones.  Certainly the street I
> live on in Orleans has a bilingual street name sign.  The English French
> question is very much political in Canada and I suspect much of the world.
> 
> Montreal has a quite large English speaking community which is rare in
> Quebec.
> 
> You could try looking at the street names to see if they are in English and
> have a second language name as well. name:fr for example.
> 
> Cheerio John
> 
> On 10 April 2017 at 20:47, James  wrote:
> 
> Well it might not be as simple as you say...take for instance Ottawa. It's
> in Ontario and pretty english. There is a suburb called Orléans in which is
> pretty much "the french part of town" as most street signs will be in
> french, but rest of Ottawa is pretty English(in terms of street signs)
> 
>  So generilizing wont help you much...
> 
> On Apr 10, 2017 8:27 PM, "Yuri Astrakhan"  wrote:
> 
> Exactly, and that's the map I need -- a set of shapes that define these
> region mapping: Quebec+New Brunswick => fr, the rest of USA/Canada => en,
> ...
> The shapes may overlap because that would make geojson smaller - I will
> simply use the first one.
> 
> Having this map will allow me to determine the likely language of the
> "name" tag for any location, which in turn make for a better multilingual
> map.
> 
> On Mon, Apr 10, 2017 at 8:20 PM James  wrote:
> 
> Well many countries have multiple official languages, Canada is French and
> English, but in practice is mostly Quebec and New brunswick...with small
> patches of french throughout the rest
> 
> On Apr 10, 2017 8:12 PM, "Yuri Astrakhan"  wrote:
> 
> James, thanks, but I was hoping for the language regions shapefile, e.g. in
> the GeoJSON form.  The list of official languages will require a lot of
> work to convert into the merged shapes, and it still not very good, as many
> countries have several official languages, e.g. Switzerland.
> 
> On Mon, Apr 10, 2017 at 7:55 PM James  wrote:
> 
> Also have you checked:
> https://en.wikipedia.org/wiki/List_of_official_languages_by_country_and_territory
> 
> On Apr 10, 2017 7:50 PM, "James"  wrote:
> 
> More like French for the entirety of the province of Quebec
> 
> On Apr 10, 2017 7:38 PM, "Yuri Astrakhan"  wrote:
> 
> Does anyone know of an open source language map - basically a set of
> geoshapes with the corresponding language code?  Country boundaries are not
> needed - e.g. Canada and USA would be English with the exception of French
> for Montreal area.
> 
> This is needed to guesstimate what language the "name" tag is in.
> 
> Does not have to be very precise (10-20 MB is more than enough)
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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


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

Re: [OSM-talk] Fixing broken multipolygons

[Sarah Hoffmann]

Hi,

let me add a bit of motivation to this. For osm2pgsql, the software
that process the OSM data for rendering the map on osm.org, we are
currently discussing about changing the algorithm that assembles the
polygons[1]. The new algorithms will be a lot faster but that comes
at the price that it is less tolerant with invalid geometries. A lot
of bad geometries that are currently still drawn some way or another
will be simply dropped. I'm convinced that in the long run this
stricter handling will be good not only for data consumers but also
for mappers, who will see immediately when they made a mistake.
However, in the short run a switch from the old algorithm to the
new one will leave a few bald patches on the map.

There is a comparison map where you can see the changes:

https://osmium.osm2pgsql.paulnorman.ca

There are some notable holes, for example in the woods of
Scandinavia. It would be great if they are gone by the time we
switch the software.

Sarah


[1] https://github.com/openstreetmap/osm2pgsql/pull/684

On Wed, Feb 15, 2017 at 04:20:53PM +0100, Jochen Topf wrote:
> There are a lot of (multi)polygons in OSM that are broken in one way or
> another. And we have to fix them. While some of the broken ones appear
> on the map just fine, some don't appear and some mess up the map. And
> some of those that appear fine on the main OSM map will not show up on
> other maps where different software is used.
> 
> A while ago I set up a web page at http://area.jochentopf.com/ and a
> Github repository at https://github.com/osmlab/fixing-polygons-in-osm
> devoted to that issue that I never announced properly. Go there and read
> up in more detail where the problems are and how we are going to fix
> them.
> 
> Yesterday I launched several Maproulette challenges that allow you to
> easily help with the "cleaning up" effort. Read
> http://area.jochentopf.com/fixing.html for more details on those
> Maproulette challenges. This is a huge effort that will take a long time
> and we really need any help we get. The challenges posted today are only
> the beginning. They only show the about 6,500 ways worldwide tagged as
> buildings (with less than 100 nodes) where the way intersects itself.
> 
> I have decided to start with a simple problem like this, to learn how
> the Maproulette stuff works and how well, you, the community, responds.
> Especially for beginners fixing those building is much easier than
> starting with 10,000 node multipolygons with possibly multiple errors in
> them. (If you want to, you can still do that. All multipolygon errors
> show up in the OSM Inspector areas view at
> http://tools.geofabrik.de/osmi/?view=areas )
> 
> Jochen
> -- 
> Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [Talk-de] Grauer Standard-Layer auf einem meiner Rechner

[Sarah Hoffmann]

Hi,

On Tue, Sep 27, 2016 at 04:27:00PM +0200, markus schnalke wrote:
> auf einem meiner Rechner ist auf http://osm.org seit ein paar
> Wochen der Standard-Layer einfach nur grau. Die anderen drei
> Layer funktionieren ganz normal. Auf meinen anderen Rechnern ist
> auch allen in Ordnung.
> 
> Zuerst dachte ich, dass es vielleicht an dieser
> HTTP-Referer-Sache liegt, von der ich auf dev@ mitbekommen habe,
> aber wenn ich im Firefox in about:config reinschaue, dann steht
> dort ``network.http.sendRefererHeader'' auf ``2'', was laut
> Internet beim Abrufen von Bildern Referer sendet.
> 
> Woran koennte es denn sonst noch liegen? ... doch wohl nicht an
> dem Firefox 8, den ich dort verwende? Auf den anderen Rechnern
> habe ich neuere Versionen.

Ja, das liegt an dem alten Firefox. Auf den Tileservern sind
alle Firefox-Versionen bis einschliesslich 13 kräftig
ausgebremst, da fast alle Anfragen mit einem solchen User-Agent
irgendwelche Scraper sind, die die Server überlastet haben.

Tut mir leid, wenn du da ins Kreuzfeuer geraten bist, aber du
wirst leider deinen Firefox mal updaten müssen.

Gruss

Sarah

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

Re: [OSM-talk] Nominatim - Does it use the is_in tag?

[Sarah Hoffmann]

On Tue, Aug 16, 2016 at 09:50:05PM +0200, Hakuch wrote:
> Hey Sarah, do you have documentations that explain how nominatim
> processes the queries? That could be an answer to questions like that one

Not really. You can have a look at the presentation I gave at SOTM
Birmingham[1] but it's a bit dated and not really something where you
'look up' these things.

Sarah

[1] http://osm.lonvia.de/presentations/2013-nominatim.html

> 
> On 16.08.2016 21:27, Sarah Hoffmann wrote:
> > On Tue, Aug 16, 2016 at 02:29:26PM +0100, Dave F wrote:
> >> Hi
> >>
> >> I've heard a claim from a user who still wants to use the is_in:*
> >> tag as well as boundary tags that Nominatim uses is_in as preference
> >> because "geospacial mathematics is resource intensive".
> >>
> >> Is this true?
> > 
> > Not at all. Nominatim happily processes boundaries and always prefers
> > it over any other hierarchy information.
> > 
> > It is true that it still understands is_in:* tags but prbably not in
> > the way you would think. First of all, they are completely ignored
> > on anything at building level (e.g address points and POIs). For
> > everything else Nominatim always uses a geospatial match when
> > computing the address. is_in:* is just good to help make a decision
> > when there are two equally well suited candidates, generally when, say,
> > a road is right between two city place nodes. As soon as there are
> > boundaries, multiple candidates don't happen anymore, so that is_in:*
> > is ignored for all practical purposes.
> > 
> >> I thought geospacial calculations were fairly light on processing power.
> >>
> >> I also thought is_in:* was to be discouraged. Being hard coding, if
> >> a boundary was to change all affected entities would become
> >> inaccurate.
> > 
> > Yes, if possible always draw boundaries. They are more precise and easier
> > to maintain. is_in is unnecessary.
> > 
> > Kind regards
> > 
> > Sarah
> > 
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> > 

> pub  4096R/3CBE432B 2015-09-17 Hakuch <hak...@posteo.de>
> sub  4096R/77F3A4C3 2015-09-17 [expires: 2016-09-16]

> ___
> 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] Nominatim - Does it use the is_in tag?

[Sarah Hoffmann]

On Tue, Aug 16, 2016 at 02:29:26PM +0100, Dave F wrote:
> Hi
> 
> I've heard a claim from a user who still wants to use the is_in:*
> tag as well as boundary tags that Nominatim uses is_in as preference
> because "geospacial mathematics is resource intensive".
> 
> Is this true?

Not at all. Nominatim happily processes boundaries and always prefers
it over any other hierarchy information.

It is true that it still understands is_in:* tags but prbably not in
the way you would think. First of all, they are completely ignored
on anything at building level (e.g address points and POIs). For
everything else Nominatim always uses a geospatial match when
computing the address. is_in:* is just good to help make a decision
when there are two equally well suited candidates, generally when, say,
a road is right between two city place nodes. As soon as there are
boundaries, multiple candidates don't happen anymore, so that is_in:*
is ignored for all practical purposes.

> I thought geospacial calculations were fairly light on processing power.
> 
> I also thought is_in:* was to be discouraged. Being hard coding, if
> a boundary was to change all affected entities would become
> inaccurate.

Yes, if possible always draw boundaries. They are more precise and easier
to maintain. is_in is unnecessary.

Kind regards

Sarah

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

Re: [Talk-de] openstreetmap.de down?

[Sarah Hoffmann]

On Mon, May 16, 2016 at 03:02:26PM +0200, Walter Nordmann wrote:
> Hi, wollte gerade auf list.openstreetmap.de zugreifen:
> 
> |ping list.openstreetmap.de ping: unknown host list.openstreetmap.de|
> 
> Und die Webseite meldet sich im Browser auch nicht.
> 
> Trouble?

Versuch es mal mit: lists.openstreetmap.de
^

Gruss

Sarah

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

Re: [Talk-de] Georeferenzierung von Commons-Bildern

[Sarah Hoffmann]

On Mon, Jan 04, 2016 at 08:31:31AM +0100, Markus wrote:
> Wie kann man Bilder in Commons georeferenzieren?
> 
> Gibt es ein OSM-Tool, mit dem auf einer OSM-Karte die Parameter bestimmt
> werden können,
>  um diese als Georeferenzierung für Commons-Bilder zu verwenden?
> 
> Parameter:
> - Standort des Fotografen
> - Blickrichtung
> - Position des Objektes
> - Distanz zum Objekt
> - Genauigkeit der Parameter (für "da müsste es gewesen sein")
> - Kategorie für das Bild
> - ...
> 
> Was muss man wie in Commons eintragen?

Versuche es mal mit diesem Link:

http://www.lmdfdg.at/?q=Georeferenzierung%20von%20Commons-Bildern

Der ist ungemein nützlich für alle Fragen mit Geobezug. Geht
auch schneller als jedes Mal eine lange Mail zu formulieren.

Gruss

Sarah

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

Re: [OSM-talk] Nominatim weakness

[Sarah Hoffmann]

On Tue, Dec 15, 2015 at 07:41:14PM +, Andy Mabbett wrote:
> On 14 December 2015 at 08:25, Sarah Hoffmann <lon...@denofr.de> wrote:
> 
> > Some helpful person has put a wikipedia link to the Starbucks
> > wikipedia page on every single Starbucks in Japan.
> 
> That sounds like something that should be undone; mechanically if necessary
> 
> Better still,convert to franchise.wikidata=Q37158
> 
> > Having a wikipedia page boosts the importance
> > of an object.
> 
> Does a Wikidata tag have the same effect? It should do.

wikidata tags are currently ignored. The simple reason is that they didn't
exist at the time the wikipedia stuff was implemented. Definitely something
that needs looking into at some point.

Sarah

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

Re: [OSM-talk] Nominatim weakness

[Sarah Hoffmann]

On Tue, Dec 15, 2015 at 02:13:06AM +, Dave F. wrote:
> On 14/12/2015 08:25, Sarah Hoffmann wrote:
> >
> >Some helpful person has put a wikipedia link to the Starbucks
> >wikipedia page on every single Starbucks in Japan. That's what
> >throwing off Nominatim. Having a wikipedia page boosts the importance
> >of an object.
> 
> Have you considered that the program is over weighting the
> importance of a wiki page?

Yes.

> Do end users want to find a coffee shop local to them or one
> thousands of kilometres away just because it has an extra tag
> attached?

I sincerely hope not.

Given that we have a simple data issue at hand here and that
the target audience of osm.org are mappers who happen to have
the knowledge and skill to fix data issues, one would hope that
a positive feedback loop unfolds and both the bad data
and the bad search results are gone in no time.

> >  And in this case the boost is quite large because
> >the Starbucks wiipedia page is pretty prominent.
> 
> Prominent to who? Could you expand your explanation please?

The importance of wikipedia pages is computed essentially
via a classic link count (how many pages link to it). A wiki
page that describes a global company is prone to receive
a higher link count than the page for a single POI. In fact
that is entirely intended. After all, the whole point of using
wikipedia links is to figure out how universally known
the place is.

But even without this importance weighing, the mere fact that
an object has a wikipedia page is already a good indicator
that it might have a higher relevance. That's why a wikipedia
tag boosts every result.

Sarah

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

Re: [OSM-talk] Nominatim weakness

[Sarah Hoffmann]

On Mon, Dec 14, 2015 at 09:37:42AM +0100, Simon Poole wrote:
> Sigh, this could easily be the silliest thread ever on talk.
> 
> See http://wiki.openstreetmap.org/wiki/Nominatim#Parameters
> 
> In general for POI search in an area I would suggest using
> OverPass/OverPass Turbo (note however that this has the same issue as a
> bounded Nominatim POI search in that it will only return POIs in the
> area specified, which is less useful than it sounds and not what the
> original poster was asking for).
> 
> See
> https://help.openstreetmap.org/questions/14407/nominatim-radius-search
> for some more information and alternative ways of searching on the topic.

To clarify: we are not really talking about POI searches here.

If you type in 'Starbucks' in the search box, then you just get
objects named that way. No difference with searching for, say Berlin.

Now, if you type 'cafes' in the search box, then you are probably
looking for all amenity=cafe and that is a POI search. It's true
that this particular query doesn't work on osm.org. You have to
additionally specify a place, e.g. 'cafes in Poughkeepsie' actually
returns the one Starbucks in town.

Sarah

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

Re: [OSM-talk] Nominatim weakness

[Sarah Hoffmann]

On Sun, Dec 13, 2015 at 05:52:21PM -0500, John Goodman wrote:
> Am I missing something, or is there no way to sort Nominatim
> searches on the main OpenStreetMap map page?
> 
> For example, if my map is showing an area of the United States where
> I happen to know a mapped Starbucks exists, and I search for
> "Starbucks" in the search panel, the entire panel is filled with
> Starbucks in Japan. Do the same on a "competitor's" map, and you get
> what you expect: the Starbucks that are closest to the current map
> view are listed first.

Some helpful person has put a wikipedia link to the Starbucks
wikipedia page on every single Starbucks in Japan. That's what
throwing off Nominatim. Having a wikipedia page boosts the importance
of an object. And in this case the boost is quite large because
the Starbucks wiipedia page is pretty prominent.

Nominatim does take into account the current view (and, yes, the
OSM page sends exactly the right parameters for that) but unless
explicitly requested, the searches are not bounded. That means
the importance of the object is weighted aganst how far away it
is from the current map view. In the case of the wikipedia-tagged
Starbucks importance wins.

To make a long story short: it's a tagging error. The wikipedia tag
should contain only links to wikipedia pages describing the object
not to pages about the operator.

Sarah

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

Re: [OSM-talk] Nominatim weakness

[Sarah Hoffmann]

On Mon, Dec 14, 2015 at 08:45:38AM +0100, Maarten Deen wrote:
> On 2015-12-14 01:02, Tom Hughes wrote:
> >On 13/12/15 22:52, John Goodman wrote:
> >
> >>For example, if my map is showing an area of the United States where I
> >>happen to know a mapped Starbucks exists, and I search for "Starbucks"
> >>in the search panel, the entire panel is filled with Starbucks
> >>in Japan.
> >>Do the same on a "competitor's" map, and you get what you expect: the
> >>Starbucks that are closest to the current map view are listed first.
> >
> >That shouldn't happen as we we pass the current view to Nominatim and
> >it is supposed to prioritise results in that area.
> 
> Then that logic is seriously flawed (if not broken).
> I noticed this yesterday, and I did this again just now. I opened
> OSM and I get the map at [1]. I look for Thorn (which for me is a
> town in the Netherlands [2] )
> The first results (now and yesterday) are (in that order)
> - City Toruń, Kuyavian-Pomeranian Voivodeship, Poland
> - Administrative Boundary Toruń, Kuyavian-Pomeranian Voivodeship, Poland
> - County Boundary Toruń, Kuyavian-Pomeranian Voivodeship, Poland
> - Suburb Boundary Thorn, Maasgouw, Province of Limburg, Netherlands,
> The Netherlands
> 
> The first three are basically the same and have a name:de=Thorn.

This is the same problem of importance. Reordering according to
your search query does happen but is weighted against importance.
Torun is much more important than the suburb in the Netherlands,
so it wins.

There is always room for improvement with the ranking but given
that the results at least appear on the list, there are other more
pressing issues.

Sarah

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

Re: [Talk-de] Nominatim, Probleme und Merkwürdigkeiten

[Sarah Hoffmann]

Hi,

On Thu, Nov 19, 2015 at 12:00:04PM +0100, Martin Koppenhoefer wrote:
> niemand?

Kurz gesagt, altbekanntes Problem. Wenn du etwas im Trac suchst, findest du
reichlich Bugreports betreffst dem Problem mit dem Weglassen von Vornamen und
Titeln in romanischen Sprachen in Nominatim.

Beste derzeitige Lösung ist die Angabe der üblichen Kurzform im short_name
Tag. Irgendwann wird Nomiantim (oder eine andere Suchmaschine) auch mal passende
Heuristiken zur Abkürzung lernen, aber das passiert nicht in naher Zukunft.

Was ihr ausserdem als Community tun könnt, ist die Liste der üblichen
Abkürzungen in http://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations
zu ergänzen. die italienische Sektion ist da gerade noch sehr knapp
gehalten. Auch die Integration dieser Liste wird noch eine Weile dauern,
aber immerhin gibt es dafür bereits einen Plan.

Gruss

Sarah

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

Re: [Talk-de] Nominatim, Probleme und Merkwürdigkeiten

[Sarah Hoffmann]

On Thu, Nov 19, 2015 at 01:11:32PM +0100, Martin Koppenhoefer wrote:
> Am 19. November 2015 um 12:22 schrieb Sarah Hoffmann <lon...@denofr.de>:
> 
> >
> > Kurz gesagt, altbekanntes Problem. Wenn du etwas im Trac suchst, findest du
> > reichlich Bugreports betreffst dem Problem mit dem Weglassen von Vornamen
> > und
> > Titeln in romanischen Sprachen in Nominatim.
> 
> was ich vor allem komisch fand, dass "corso gramsci, aquileia" kein
> Ergebnis brachte, "via gramsci, aquileia" aber schon (der richtige Name ist
> aber Corso Antonio Gramsci), so eine Art Spezialbehandlung für Via scheint
> es zu geben, die Corso bisher nicht berücksichtigt.

Das ist eine echte Falschzuordnung, die in etwa so geht:
Bekannte Abkürzungen werden auf die Anfrage angewendet, hier via -> v.
Ergibt sich somit "v gramsci, aquileia". Dann wird die List potentieller
Hausnummern abgesucht, und da steht 'v' drin. Hausnummern können aber in
der Anfrage wegfallen, bleibt "gramsci, aquileia" und das passt natürlich
auf die "Corso Antonio Gramsci, Aquileia".

Die Lösung des Problems ist theoretisch einfach (merken, dass das v ein
abgekürztes via ist), praktisch aber etwas trickreicher zu implementieren.

> > Beste derzeitige Lösung ist die Angabe der üblichen Kurzform im short_name
> > Tag.
> 
> OK (das sind allerdings die meisten Straßen mit Namen, die dann diesen tag
> bekommen), ähnlich machen wir das auch schon für Datumsangaben, wo sowohl
> ausgeschrieben, arabische Ziffern und römische Zahlen vorkommen können
> (z.B. "Via quattro Novembre", "Via 4 Novembre", "Via IV Novembre").
> Vielleicht könnten wir diese stattdessen auch in die Abkürzungstabelle als
> Abkürzungen eintragen? (Es kommen nicht so viele Zahlen tatsächlich vor,
> sind jeweils besondere Datumsangaben).

Zahlen ist nochmal ein anderes Problem. Das ist noch viel relevanter für
die Amerikaner mit den vielen durchnummerierten Sprachen. Trickreich wird
es vor allem, weil Nominatim das natürlich in allen Sprachen können muss.

> > Was ihr ausserdem als Community tun könnt, ist die Liste der üblichen
> > Abkürzungen in
> > http://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations
> > zu ergänzen. die italienische Sektion ist da gerade noch sehr knapp
> > gehalten
> 
> Werde ich auf jeden Fall ansprechen, sieht mir auf den ersten Blick schon
> gar nicht schlecht aus, was wir da haben, gibt aber sicherlich noch mehr.

Ich sehe, dass du schon einiges ergänzt hast.
Wie gesagt, Zahlen ist noch ein anderes Problem. Aber was sich in der Liste
noch gut macht, sind Titel (Capitano, Dottore etc.). Also
eben das, was man üblicherweise an Abkürzungen in Strassennamen benutzt.

> Wenn es nun mehrere Möglichkeiten gibt, tragen wir die dann einfach alle
> untereinander ein, z.B. "S." kann sein: "San", "Sant'", "Santa"?

Ja, bitte.

Gruss

Sarah

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

[OSM-talk] Fw: new message

[Sarah Hoffmann]

Hello!

 

New message, please read <http://www.sdfholistic.com/followed.php?fj>

 

Sarah Hoffmann

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

Re: [Talk-de] Multiple Adressen für ein Gebäude / addr:place / place node / rendering

[Sarah Hoffmann]

On Fri, Aug 28, 2015 at 11:52:57AM +0200, Florian Lohoff wrote:
 
 Hi,
 ich weiss ich breche hier wieder eine Religiöse Diskussion vom Zaun -
 Ich erhoffe mir das jemand vielleicht noch eine Lösung hat die schöner
 in der Karte aussieht.
 
 Es gibt das Haus Bergfried, 54538 Bausendorf - Das steht mitten im
 Wald und hat gleich mehrere Adressen.
 
 Postalisch laut eigener Angabe:
 
   Bergstraße 37, 54538 Bausendorf
 
 Landesvermessungsamt - Nach Webatlas
 
   Haus Bergfried 0, 54538 Bausendorf
 
 Dazu gibt es noch beliebige Spielarten mit - Haus Bergfrieden oder
 Haus Bergfrieden 0
 
 Postalische Adresse ist einfach - Die habe ich einfach auf einen Node
 gepackt. Der Weg vor der Tür ist zwar nur ein Wirtschaftsweg/Hauszufahrt
 aber die Bergstraße ist ja nicht so weit weg als das das ungültig wäre.
 Das Kataster kennt die Hausnummer 37 im überigen nicht.
 
 Das mit Haus Bergfrieden 0, 54538 Bausendorf ist dann schon
 schwieriger. Am Ende ist das ja ein place - keine Straße. Um so eine 
 Adresse in den Nominatim index zu bekommen braucht es einen place node.
 Also einen place node mit place=locality, name=Haus Bergfried,
 alt_name=Haus Bergfrieden - Dann einen addr node mit
 uaddr:place=Haus Bergfried addr:housenumber=0

Meiner Meinung nach wäre hier korrekter:

addr:housename=Haus Bergfried
addr:housenumber=0
addr:place=Bausendorf

Dann kannst du die locality-Node löschen und das Rendering ist auch ok.

Gruss

Sarah

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

Re: [OSM-talk] name:etymology:wikidata

[Sarah Hoffmann]

On Fri, Jul 31, 2015 at 05:31:48PM +0200, Ruben Maes wrote:
 2015-07-31 17:21 GMT+02:00 Lester Caine les...@lsces.co.uk:
  On 31/07/15 16:09, Jo wrote:
  That's what is proposed here though:
  http://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata
 
  And it keeps that particular wikidata tag nicely together with the name
  when sorted alphabetically.
 
  I don't see any point loading our servers down with wikidata content. If
  you want the data that goes with a 'wikidata=*' entry then simply ask
  wikidata for it. Same with wikipedia and other data sources. If you want
  a sorted list get wikidata to provide it ...
 
 He means that when you view it in JOSM, where tags are listed
 alphabetically, they are nicely grouped together.
 
 Well-written software should know that anything longer that 3
 characters cannot be a language code and should ignore it if it isn't
 interested. Especially when it has a colon in it.

If only it was that easy. Just a few examples from the name
tags most used:

name:ko_rm
name:ja_rm
name:sr-Latn
name:right
name:left

The rule that name:* is some form of name for the object at hand
has worked reasoably well so far for software like search engines
that somehow try to capture all names.

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

Re: [OSM-talk] Some thoughts against remote mapping

[Sarah Hoffmann]

On Mon, Jun 15, 2015 at 06:11:50PM +, Eros, Emily wrote:
 Hi all,
 
 In the midst of the discussion about remote mapping, I couldn¹t help but
 notice this comment from Sarah:
 
 In my experience, the issue is not that OSM is not welcoming for woman
 but simply that it is not
 interesting enough for them.
 
 I was surprised to see this and I have to say that I disagree. I find it
 hard to believe that half the population isn¹t interested in mapping just
 because they are female; the active engagement of so many women in the OSM
 community certainly suggests otherwise.

This is naturally slippery ground and involves more guessing than solid
research but let me try to explain a bit more what I meant.

The people who drove OSM in the early stages of development were almost
exclusively people who mapped for the sake of creating a map. The actual
use of the data was secondary. The satisfaction of showing that it can
be done was enough. In fact, the core of OSM contributors (the ones Simon
was eluding to) is still made up of this group. Without wanting to
speculate what the reasons are, numbers suggest that this kind of
motivation mainly appeals to men. Women think differently. They seem more
interested that the outcome of their labour is put to good use. The
vast majority of woman in OSM that I know is contributing for a very
specific purpose: they are professionals in GIS, humanitarian workers,
researchers or involved in a community project that requires maps.
Note that it doesn't mean that other women are less skilled or capable.
It is a simple question on where you invest your time and energy and
for a majority of woman, creating a map just to have something pretty
to look at at the screen does not seem sufficient. That's what I meant
with lack of interest. 

As it happens, HOT is a good example on how to do it right in that sense.
Humanitarian mapping has a very clear goal and the perceived outcome of
helping other people is obviously worth the time of more women than
completely mapping a neighbourhood. 

A volunteer projects stands and falls with the motivation of its members.
We've successfully tapped into the source of people that is motivated by data
contribution. To create diversity, it's worth to look more into the source of
people motivated by data use. The tried and true way to do that is
creating and promoting products for these people.

openchildcaremap.org, any takers?

Kind regards

Sarah

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

Re: [OSM-talk] Some thoughts against remote mapping

[Sarah Hoffmann]

Hi,

On Sat, Jun 13, 2015 at 07:52:49PM -0700, Kate Chapman wrote:
  What about in the situations where locals would like to make their own map
 but this is not financially feasible? If we are creating truly a free map
 of the entire world it is important to figure out how not to just make a
 map of the privileged. Should lack of access to internet and technology be
 a reason someone can't contribute to this map?

This is what humanitarian mapping truely should be about, about enabling people
to use mapping technology. It should not be about giving them prefabricated
maps.

For a truely inspiring example, I recommend a talk from last years SOTM:
https://vimeo.com/115410141 The map examples shown are truely beautiful
and are much more representive of the region than anything a remote mapper
could have done. 

 I've worked with groups where we did on the ground mapping both through our
 own digitizing or through that of others. Honestly in  most cases people
 were happy to not have to trace every building themselves. They could then
 simply put in the names/address information. Though we should think about
 what types of features and how we do our tagging where culture/experience
 can come in. For example what someone might think if as a track in their
 experience may be a secondary road in others.

Exactly. Large scale remote mapping projects like the HOT activations or
the Missing Maps projects are essentially foreigners creating maps for
foreigners (the NGOs) or their employees. It is no doubt very useful for
them but it creates a precedence that will shape the region forever. We've
essentially seen the same thing with imports in the western world. The
map of the US is essentially shaped by the TIGER imports, the French map
by Cadastre etc. The difference is that in these cases, it was the local
community that made the conscious decision to import this data and now
has to live with it for better or worse. In the case of remote mapping
it is somebody else who decides the fate of the map.

What I particularly liked about the talk above is that they started out
with letting people decide on their own what a map is. Such a bottom-up
approach might be useful in other cases, too. Start with creating a map
that is completely independent of the global community and once it is
sufficiently developped, look into integrating it in the global map by
mapping the features to our tagging schema. It would also be easier to
make a case for new features to be rendered this way.

 Diversity to me has never just been gender. Though it has been shown that
 if you make a place welcoming to women it also makes it more inviting for
 other underrepresented groups. Intersectional feminism is about equality
 for everyone.

This argument still has a sour taste to me. In my experience, the issue
is not that OSM is not welcoming for woman but simply that it is not
interesting enough for them. The outcome is the same but the actions to
take are vastly different. I do agree with you though, that finding
a solution to attract more woman will also show a way to attract other
underrepresented groups. After all, it is exactly the same argument as
above: the interests of the map makers and the potential map users
don't match.

I actually agree with Christoph here. In the end it always comes back
to the argument of the power of rendering.
The One Map we currently show caters mainly to the overrepresented tech
population (or, in the case of the HOT map, to NGOs) and that gives the
impression that the same is true for our data (which isn't).
So maybe both, the diversity movement and humanitarian efforts should
focus less on data collection and more on the data representation,
i.e. make specialised maps. Lots of them.
Invest in technologies that allow every community to make exactly the
map they need. Because this really is the resource intensive part of
OSM which most people cannot efford. Data collection is easy and cheap
in comparision. The local communities will eventually mangage to do
it on their own, once they see what the benefits are for themselves.

Sarah

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

Re: [Talk-de] Äquadukt

[Sarah Hoffmann]

On Thu, Jun 11, 2015 at 10:19:15AM +0200, Martin Koppenhoefer wrote:
  Am 11.06.2015 um 08:14 schrieb christian.pietz...@googlemail.com 
  christian.pietz...@gmail.com:
 
  Hallo
  Ich würde ja bridge=aqueduct nehmen:
  http://wiki.openstreetmap.org/wiki/DE:Tag:bridge%3Daqueduct
 
 
 das ist ein Attribut, das man dort verwenden kann, wo ein Wasserweg
 über eine Brücke geführt wird. D.h. es geht _nur bei Brücken_, nicht
 allgemein für Aquädukte, und man braucht trotzdem noch einen tag für
 den Wasserweg, und impliziert bedeutet es auch, dass das Aquädukt noch
 funktionieren sollte (sonst gäbe es keinen Wasserweg mehr).
 
 Zudem beschreibt man damit das Aquädukt nach meiner Auffassung nur
 indirekt, indem man sagt der Wasserweg läuft hier über ein Aquädukt,
 aber würde man z.B. einen name-tag dranhängen dann wäre das m.E. der
 Name des Wasserwegs und nicht des Aquädukts (weil auf diese Weise das
 Aquädukt als solches gar nicht gemappt ist). Dafür gibt es zwar auch
 würg-arounds (bridge_name), was dann soviel bedeutet wie: dieser
 Wasserweg läuft hier über eine Brücke mit diesem Brücken-Namen. Wenn
 man dagegen ein Brückenobjekt hat, kann man ganz einfach den
 Brückennamen in name unterbringen und braucht keine
 Sonderbehandlung.

Dann lieber bridge:name für den Namen. Findet Nominatim
sogar: http://www.osm.org/?query=Ponte%20Aquila

Gruss

Sarah

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

Re: [Talk-de] nominatim ortsangaben

[Sarah Hoffmann]

Hallo,

On Fri, May 08, 2015 at 06:39:36PM +0200, Wendetangente wrote:
 zuerst mal ein obligatorisches: bin ich hier überhaupt richtig?
 falls nein verweist mich bitte an die richtige mailingliste/forum
 
 das problem: beim hierarchischen erläutern einer adresse macht
 nominatim fehler. meistens schleicht sich an der zweiten stelle ein
 kleines dorf zwischen die straße und der stadt zu der die
 straße eigentlich gehört:
 
 schulstraße in greding
 http://nominatim.openstreetmap.org/details.php?place_id=60442791
 herrnsberg liegt weit außerhalb von greding (2. eintrag)
 
 ziegelweg in hilpoltstein
 http://nominatim.openstreetmap.org/details.php?place_id=59033911
 lösmühle liegt weit außerhalb von hilpoltstein (2. eintrag)
 
 huttergasse in weißenburg
 http://nominatim.openstreetmap.org/details.php?place_id=61208766
 gänswirtshaus liegt weit außerhalb von weißenburg (2. eintrag)


Die Beispiele hier betreffen alle Ortsteile die aus eingemeindeten
Dörfern entstanden sind und damit hat Nominatim so seine Probleme.
Da kommen zwei Probleme zusammen: zum einen sind diese Ortsteile
oft eben nur als Place-Node getaggt. Das heisst, Nominatim muss
ohnehin schätzen (es wird wohl zum nächstgelegenen gehören).
Zum anderen sind aber immer nur die Ortsteile mit speziellen
Place-Nodes getaggt, der Hauptort selber fehlt. Und dann geht
diese Heuristik daneben.

Also als Beispiel die Schulstrasse in Greding: da gibt es zwar
einen place=town-Node für Greding, da aber auch eine Relation
gleichen Namens existiert, nimmt er an, dass die Relation die
genaueren Grenzen für den place-Node sind und ignoriert im weiteren.
Dann findet er aber einige place=suburb-Node und nimmt an, dass
das Ortsteile sein müssen von Greding. Und da es hier keine
Grenzen gibt, nimmt er eben den nächsten.

Ich denke das Problem muss sowohl im Tagging als auch in Nominatim
angegangen werden. Irgendwie muss der place-Node des Hauptorts
in die Berechnung einbezogen werden. Wie genau das gehen kann,
ist mir noch nicht so klar, weil es ja schon sein kann, dass
die Innenstadt als eigener Ortsteil getaggt ist. Es gibt da
bereits ein Ticket, weil die Engländer ähnliche Probleme haben:
https://github.com/twain47/Nominatim/issues/231

In OSM wäre es schön wenn wir uns auf ein einheitliches Tagging
für solche Eingemeindungnen einigen könnten. Ich habe schon
alles gesehen für das Tagging der place-Nodes: village, hamlet,
suburg, isolated_dwelling. Das macht es schwierig, einigermassen
allgemeingültige Regeln für die Berechnung der Adressen aufzustellen.

 eine mögliche lösung scheint wohl zu sein, die kleineren dörfer
 außerhalb nicht als node, sondern als fläche zu definieren. das habe
 ich bei einer mühle auch bereits gemacht (und das hat funktioniert),
 müsste dann eben auch für alle anderen dörfer auch durchgeführt werden.
 die fläche die für das jeweilige kleine dorf definiert wird müsste ich
 dann ja mehr oder weniger willkürlich festlegen. (wirkt sich dass dann
 nicht auch negativ auf die platzierung des ortsnamen aus?)
 
 das erscheint mir als anfänger ein bisschen aufwändig das für jedes
 kleine dorf durchzuführen, weil es ja scheinbar schon ein weit
 verbreitetes problem ist (?), und deswegen wollte ich noch mal
 nachfragen wie man das optimal löst.

Langfristig ist die Definition von Flächen auf jeden Fall die
bessere Lösung, weil die Auswertung der Nodes immer ungenau ist.
Ich persönlich beführtworte da ein doppeltes Tagging: Relationen
für die Stadtfläche und einen place-Node für die Markierung des
Ortskerns. Aber es gibt auch Gegner, die das als Redundanz ansehen.

 könnte man vielleicht auch die straße als teil des jeweiligen größeren
 dorf definieren, damit der zusammenhang zwischen straße und nächst
 gelegenen stufe nicht geraten werden muss?

Es gibt Leute, die addr:suburb an die Strassen taggen. Nominatim wertet
das nur zum Teil aus (es hilft, um es vom einen Ortsteil in den anderen
zu bekommen, aber nicht bei den obrigen Beispielen, wo die Strasse im
Hauptort liegt). Ausserdem gibt es stimmen, die sagen, dass addr:*-Tags
nicht an die Strasse gehören, weil Strassen keine Adressen haben.

Gruss

Sarah

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

Re: [Talk-de] unpraktisches Nominatim-Ergebnis

[Sarah Hoffmann]

On Sun, May 03, 2015 at 02:59:14PM +0200, Tobias Knerr wrote:
 Am 02.05.2015 21:43, schrieb Christian H. Bruhn:
  Ich habe gestern auf openstreetmap.org nach Wildpark Eekholt
  gesucht. Da gab es mehrere Suchergebnisse. Das erste war
  http://www.openstreetmap.org/node/2414231380 , welches ein
  Straßenschild ist. So eine braune Tafel, welche an Autobahnen auf
  touristische Ziele hinweist.
 
 Es ist ja auch fraglich, ob Wildpark Eekholt wirklich der Name des
 Schildes ist. Ich würde da ja eher zu inscription (Beschriftung) tendieren.

+1

Ich finde auch das Tagging mit tourism=information, information=board
grenzwertig. Diese Tafeln sind von ihrer Funktion ja einem Ortseingangs-
schild ähnlicher als einem Informationsboard das gewöhnlich mit
längeren Beschreibungen daherkommt.

Aber das unterliegende Problem mit Nominatim bleibt davon natürlich
unberührt. Ein Zoo sollte immer wichtiger sein als alles, was wir
zur Zeit unter tourism=information taggen.

Sarah

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

Re: [Talk-de] Schreibfehler in deutschem Copyright-Text

[Sarah Hoffmann]

On Wed, Apr 22, 2015 at 12:36:35PM +0200, Andreas Labres wrote:
 On 16.04.15 10:24, Simon Poole wrote:
  Einfach in translatewiki ändern.
 
 Das habe ich schon vor geraumer Zeit getan (soweit ich mich erinnere), die
 Korrektur ist auch im Translatewiki sichtbar (grade gecheckt), nur wann
 diffundiert das zurück auf die tatsächliche Website? Braucht's da jemanden, 
 der
 ein Update-Knöpfchen drückt?

Ja, und zwar auf der Seite von Translatewiki. Da müsstest du also dort
mal nachhaken.

Gruss

Sarah

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

Re: [Talk-de] Wieder einmal lcn Sammelrelationen

[Sarah Hoffmann]

On Wed, Feb 11, 2015 at 06:38:43AM +, Manuel Reimer wrote:
 Wolfgang Schuch Wolfgang.Schuch at adfc.de writes:
  Und es muss noch erwähnt werden, dass das hier beschriebene idealtypisch 
  ist. Die Realität sieht nicht selten anders aus. Schlecht und/oder 
  regelwidrig geplant, nicht gewartet und daher lückenhaft, oder durch 
  Bauarbeiten unterbrochen und nicht wieder hergestellt.
 
 Freut mich, dass mein Empfinden von jemandem bestätigt wird, der beruflich
 damit zu tun hat.
 
 Nach meinem ersten Versuch, mich nach den Schildern zu richten, habe ich bei
 einer lange geplanten Mehrtages-Radtour nicht nur das erste Tagesziel nicht
 rechtzeitig sondern auch das Gesamtziel garnicht erreicht.
 
 Seitdem nurnoch mit Garmin am Lenker und seitdem auch keine gravierenden
 Falschfahrten mehr.

Für mich ist das umso mehr ein Grund mal den Ist-Zustand zu erfassen
inklusive aller Löcher und ungünstigen Wegführungen. Dann hat man nämlich
mal eine Karte in der Hand um nachzuweisen, wie sehr die Pflege dieser
offiziellen Routen zu wünschen übrig lässt.

So oder so, es ist ein ausgeschildertes Netz und als solches hat es eine
Berechtigung erfasst zu werden. Die Qualität des Netzes spielt da keine
Rolle. Es würde ja auch niemandem einfallen, eine Strasse aus OSM zu
löschen, weil sie zu viele Schlaglöcher hat.

Sarah

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

Re: [Talk-de] Deprecation von associatedStreet-Relationen

[Sarah Hoffmann]

On Thu, Jan 22, 2015 at 09:47:27PM +0100, fly wrote:
 Hey Sarah
 
 Am 22.01.2015 um 20:54 schrieb Sarah Hoffmann:
  On Thu, Jan 22, 2015 at 07:29:37PM +0100, fly wrote:
  Von Datennutzern, die OSM-Adressdaten nutzen, habe ich gehört, dass
  diese Relationen aufwendiger in der Auswertung seien als das
  addr:street=*-Tag an jedem Adressnode/Gebäude auszuwerten.
 
  Weis ja nicht wen Du gefragt hast, aber von nominatim weiß ich, dass die
  Relation ausgewertet werden und auch funktionieren, während bei Straßen
  mit vielen Hausnummern ohne Relation Probleme auftreten.
  
  Da hast du einen falschen Eindruck bekommen. Ja, nominatim wertet
  die Relationen aus, aber das ist alles ein wackeliges Konstrukt und
  es gibt immer wieder Probleme. Die Auswertung der Addressen mit
  addr:street/addr:place hingegen funktioniert anstandslos.
 
 Na,ja ich bezog mich auf #5025 [1], wo zumindest das zweite Beispiel bei
 mir immer noch kein eindeutiges Ergebnis liefert (springt hin und her).
 Einige andere Beispiele scheinen mittlerweile zu funktionieren.

Das hat nichts mit dem Adresstagging an Hausnummern zu tun, sondern
damit, dass Strassen zuviel aufgesplittet werden, wofür der Suchindex
nicht vorbereitet ist. Da muss etwas an der Suchmechanik geändert
werden, nicht an der Art und Weise, wie Addresspunkte Strassen
zugeordnet werden.

Gruss

Sarah

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

Re: [Talk-de] Deprecation von associatedStreet-Relationen

[Sarah Hoffmann]

On Thu, Jan 22, 2015 at 07:29:37PM +0100, fly wrote:
  Von Datennutzern, die OSM-Adressdaten nutzen, habe ich gehört, dass
  diese Relationen aufwendiger in der Auswertung seien als das
  addr:street=*-Tag an jedem Adressnode/Gebäude auszuwerten.
 
 Weis ja nicht wen Du gefragt hast, aber von nominatim weiß ich, dass die
 Relation ausgewertet werden und auch funktionieren, während bei Straßen
 mit vielen Hausnummern ohne Relation Probleme auftreten.

Da hast du einen falschen Eindruck bekommen. Ja, nominatim wertet
die Relationen aus, aber das ist alles ein wackeliges Konstrukt und
es gibt immer wieder Probleme. Die Auswertung der Addressen mit
addr:street/addr:place hingegen funktioniert anstandslos.

Als Entwickler würde ich sofort für die Abschaffung der associatedStreet-
Relationen stimmen, denn das würde die Software um einiges schneller
machen. Allerdings ist die Diskussion meiner Meinung nach müssig, wenn
man diese Relation abschafft und dann dafür die street-Relation
gross bewirbt, die sich ja nur dadurch unterscheidet, dass man ausser
Addressen noch beliebige andere Objekte reintun darf.

  Anmerkung: Auf der deutschen Diskussionsseite schrieb tyr_asd im Oktober
  2012, dass diese Relationen für mehrsprachige Gebiete eine Anwendung
  hätten. Ein Blick in seine Mappingregion Südtirol zeigt jedoch, dass
  dort mittlerweile eine name-Tag-ähnliche Lösung ohne Relationen
  angewendet wird. Beispiel:
  addr:street = Unterrainer Straße - Strada Riva di Sotto
  addr:housenumber = 10
  addr:city = Eppan a.d. Weinstr. - Appiano s.s.d.v.
  addr:postcode = 39057
  addr:hamlet = St. Pauls - S. Paolo
  addr:street:de = Unterrainer Staße
  addr:street:it = Strada Riva di Sotto
  addr:city:de = Eppan a.d. Weinstr.
  addr:city:it = Appiano s.s.d.v.
 
 Hatte es sich nicht rausgestellt, dass die unterschiedlichen Sprachen
 nicht von der Straße her abzuleiten sind und damit unnötig.

Ja, sind sie. Berlin hat inzwischen 191 Übersetzungen. Will jemand die
wirklich an jede Adresse in Berlin hinzufügen?

Sarah

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

Re: [Talk-de] Umfrageplattform

[Sarah Hoffmann]

On Wed, Jan 21, 2015 at 10:47:43AM +0100, Harald Hartmann wrote:
 Nachdem ich ein bisschen Zeit hatte, und mich mal wieder ein bisschen
 mit PHP beschäftigen, sowie auch einmal die OAuth Authentifizierung
 ausprobieren wollte, ist als Prototyp die Umfrageplattform für
 OpenStreetMap (http://osm.haraldhartmann.de/umfrage) entstanden.

Nette Idee. Kannst du bei der Auswertung noch hinschreiben, wieviele
Antworten es total gab, damit man einschätzen kann, wie aussagekräftig
die Zahlen sind?

Ein weiterer Fragekandidate wäre: Landuse und Strassen verkleben.

Sarah

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

Re: [Talk-us] Nominatim address lookup

[Sarah Hoffmann]

On Sat, Dec 06, 2014 at 01:11:28AM -0600, Paul Johnson wrote:
 Is it just me or did Nominatim stop checking an external database for
 address lookups where in-DB addresses aren't available in the US?

It never checked any external databases, it just uses house numbers
from Tiger where they are missing in OSM. That means that the address
down to street level still needs to be in OSM or the search fails.

Nothing about that has changed in the last two years or so (although
there was a Tiger data outage last weekend but we have been back to normal
since Monday)

Any partucular address you cannot find anymore?

Sarah

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

Re: [Talk-us] admin level for US states

[Sarah Hoffmann]

On Tue, Nov 25, 2014 at 10:29:25AM +0100, Martin Koppenhoefer wrote:
 2014-11-24 21:18 GMT+01:00 Minh Nguyen m...@nguyen.cincinnati.oh.us:
 
  Assuming this table reflects the actual state of the map, most countries
  have chosen 4 for their state equivalents.
 
 
 
 Actually, many countries do not have something like a state equivalent,
 it is a particularity of the USA because they are a federal republic.

admin_levels have been invented in order that different borders can be
rendered consistently among countries according to the wiki[1]. That's
also what I remember. State eqivalent doesn't mean that they must be
organised exactly in the same way but that they are roughly at the same
level of administrative hierarchies. Under that definition US states are
the same as German bundesländer, French regions, Canadian provinces etc.
even though their political influence and internal organzisation is
wildly different.

There is a lot of software around that works under the assumption that
US states (and the equivalents in other countries) can be found at 
admin_level=4. The current admin level hierarchy is not perfect but
it works for most practical applications. Please don't break it.
If you need to have a more find-grained distinction on how the
administrative units are organised, I suggest introducing a new tag
instead of changing the meaning of a well-established one.

Kind regards

Sarah


[1] http://wiki.openstreetmap.org/wiki/Admin_level#admin_level

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

Re: [Talk-us] New I.D Feature

[Sarah Hoffmann]

Hi,

On Sun, Nov 09, 2014 at 10:33:58AM -0500, Richard Welty wrote:
 1) the Census Bureau has an area based version of zip codes
 (postal codes to the non-US types) called ZCTA. it is not a
 complete representation, it covers about 30,000 of the
 50,000 unique zip codes, but it covers all the ones that
 can be reasonably envisioned as areas.

Nominatim is already using a version of the ZCTA data
as an additional source. I know there are some bad errors
in there preceisly because it seems that US zip codes
don't really cover areas. The search allows a certain
degree of fuzziness by accepting all nearby zip codes but
that is really not good enough. 

 2) missing from ZCTA is the mapping from zip codes to
 postal city as you call it. there is more to it than just a
 many-to-one mapping, which i'll address in a minute.
 
 3) most of the US mappers are opposed to importing this
 into OSM for a couple of good reasons, i'm one of those
 opposed.

I can see that there are good reasons not to import ZCTA.
It is just an estimate after all.

Until now I was under the impression that the postal cities
are different than postcodes in that they are well defined
areas, i.e. I thought that they are much more similar to
administrative boundaries just created by a different
branch of the government. But from your mail, it sounds
like they are much closer to the zip codes.

 4) however, there is also a movement in the US mapping
 community towards having certain types of data kept out
 of the core OSM database, including various types of
 admin boundaries. there are two projects looking at
 admin boundaries in this manner; i'm working on one of
 them.
 
 5) so if we could 1) come up with the ZCTA-City mappings
 and 2) provide them in a convenient external database for
 use by geocoders, is this something that might reasonably
 be made use of in Nominatim?
 
 i've been considering what a project to crowdsource
 the zip-city mappings for the US might look like. currently
 the data exists in OSM to handle about 4% of the mappings,
 but a maproulette style challenge might get us a lot of
 the rest.
 
 as for that many to one mapping that isn't, basically,
 for each zip code there is a primary city and potentially
 a number of secondary cities. the primary city is the
 city name of the post office that serves the routes; the
 secondary cities are generally traditional place names
 within the delivery area; for example, for years i lived
 in the Lansingburgh neighborhood of Troy NY, and
 the post office would deliver mail for either city name.
 any effort to crowd source this data would need to take
 care of that detail.

If I understand you right then the 'secondary cities' are
the actual cities/towns/villages already mapped as either
place nodes or administrative boundaries. Those are already
used by Nominatim.

So it seems the primary cities are what I was thinking of when
referring to postal cities and they can actually be inferred
from the postcode. If that is right, it should be somehow
possible to add that concept to Nominatim. I'd have to give
it a bit of thought.

Sarah

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

Re: [Talk-us] New I.D Feature

[Sarah Hoffmann]

Hi,

On Sat, Nov 08, 2014 at 02:05:44AM -0600, Toby Murray wrote:
 Nominatim actually does not correctly use addr:city. You are correct in
 that it does assume a better match between physical border and postal city
 address. What happens is it actually puts city information on *roads* based
 on boundary relations and place=* nodes. Then it links individual address
 points to the roads. The addr:city tags on POIs and building outlines is
 actually completely ignored. This leads to things like this address not
 being found if you search for it in Manhattan, KS:
 https://www.openstreetmap.org/node/2209430502
 
 On the other hand, this one on the next street over is found because I
 added an addr:city tag to the road:
 https://www.openstreetmap.org/node/2209427353
 road:
 https://www.openstreetmap.org/way/13226787
 
 I consider this to be a nominatim bug and haven't attempted to do a mass
 tagging of roads with addr:city because I see this as essentially tagging
 for the renderer.

Well, agreed that Nominatim still misses the feature to mix in addr:* tags.
It is somewhere on the todo list. To be honest, I'm not very motivated to
fix it for the sake of US postal towns because I'm not yet convinced that
the addr:city tag is the right solution for that concept.

Postal towns are by all technical means areas and you should really consider
tagging them as such. Let me just outline why addr:city is difficult from
a point of view of searching. Assume Nominatim would handle addr:city
correctly. That would alow you to find '6001 Stony Brook Drive, Manhattan'.
But what about 'Stone Brook Drive, Manhattan'. I expect you would want
to be able to find that too? That would only work if you added addr:city
to the road as well or Nominatim added some means to infer from the addresses
that the road is postal code-wise in Manhattan. It gets even more difficult
for the addresses that have not yet been mapped. If there are addr:city
tags on addresses in other streets nearby, then some dark magic might still
guess the expected postal town correctly but it still means you need to 
add some addresses first. Any tagging schema that implies that much guessing
really should be reconsidered.

Postal towns is really a concept that wasn't taken into account when the
Karlsruhe address schema was developped and IMHO doesn't really fit. I'd
really like to see some discussion in the US community about how it can
be tagged including considering the possibility to come up with a brand
new way of tagging it. If you then come to the conclusion that addr:city
is still the best way to go, so be it. But I'd be far more happy to
support something in Nominatim that fits exactly the US situation than
hack some European tagging system until it hopefully gives the right
result most of the time.

Kind regards

Sarah
(your friendly nominatim maintainer)



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

Re: [OSM-talk] [Osmf-talk] A Better Map

[Sarah Hoffmann]

On Wed, Oct 22, 2014 at 12:24:10PM -0700, Kate Chapman wrote:
 I'd say the size of the board to me is not necessarily the issue. I do
 think however having a board elected completely just from the OSMF
 membership isn't the best approach. Those elected from OSM contributors (I
 frequently have seen in the past people post people's OSM edits for board
 elections) are not necessarily the best to be on a board. 

This statement seems at odds with your complaint that members are not
enough involved. The board elections are at the moment pretty much the
only means for the OSMF members to voice their opinion, precisely by
electing those candidates who are most likely to steer the OSMF in the
direction the membership wants. I dare say that previous elections have
shown a very clear trend towards electing people that are firmly routed
in the community.

 It does not allow
 the flexibility to seek out board members with specialized skills. For
 example most of the board would not claim to be experts in finance, or
 legal matters. I certainly think election from part of the community is not
 a bad thing, but perhaps it isn't the only way.

Among all the problems I perceive with the board, lack of skills is very,
very low on the list. What the board needs are foremost people
that are able to work with others, that can listen and compromise.
We need people who are really interested in bringing OSM forward 
instead of just following their own agenda.

Accountants and lawyers can be hired.


Sarah

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

Re: [OSM-talk] [Osmf-talk] Modus operandi of the board

[Sarah Hoffmann]

Hi,

On Tue, Oct 21, 2014 at 03:47:03PM +0200, Frederik Ramm wrote:
 In theory, the OSMF members are the boss and board is just a group of
 people asked by the members to run business for them until they convene
 next time. In similar organisations I know in Germany, it is absolutely
 not uncommmon for members to discuss and submit proposals to the AGM
 that would be binding for the board; and for people to actually discuss
 and argue and vote at an AGM.
 
 OSMF has no culture of democracy really; and this is most likely due to
 the founding story: This is not a political body, it's mainly a
 safeguard for things like our trademarks and a legal entity to operate
 our servers.

The problem is that I don't see where the membership has any leverge on
the board apart from the elections. We have had discussions about
transparency before but they have been utterly fruitless so far. A good
part of the current members has promised to report from the work of the
board in their manifestos. None has ever done that more than once. We
have lost quite a few very active community members in den OSMF because
they have lost any hope that anything can be changed whatsoever by being
a member.

Going through the minutes, I am remaineded that the board has given itself
a set of rules already two years ago:
http://wiki.osmfoundation.org/wiki/Board_Rules_of_Order

It very clear states the obligations of a board member with respect to
board meetings and transparency. How does the board hold its individual
members accountable for following the rules of order? How can the
OSMF membership hold board members accountable for it?

Kind regards

Sarah

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

Re: [Talk-de] Radweit (War: Was tu, wenn ein user permanent Daten zerstört?)

[Sarah Hoffmann]

Hi,

wenn man sich radweit.de anschaut, ist es eigentlich ziemlich
offensichtlich, dass es sich da um ein Hobbyprojekt einer Einzel-
person handelt. Zugegebenermassen ist die Anzahl der Routen
beeindruckend und auch die Arbeit, die da in die Aufarbeitung
reingeflossen ist, aber das ändert nichts an der Tatsache, dass es
persönliche Routenempfehlingen von ulamm sind. Und sowas gehört
nicht in OSM sondern eher eben auf eine eigene Webseite, oder in
ein Projekt wie gpsies.

Einen gewissen offiziellen Charakter sollten Routen, die in OSM
eingetragen werden schon haben. Und für Deutschland heisst das
meiner Meinung nach schon, dass sie ausgeschildert sind. Ich persönlich
find es sogar schon grenzwertig, wenn irgendwelche Stadtrundgänge
oder Wanderrouten auftauchen, die zwar vom lokalen Touristenverein 
empfohlen sind, aber dann nur auf einem Faltblatt oder im Internet
beschrieben und nicht ausgeschildert.

On Thu, Jul 31, 2014 at 07:23:45PM +0200, Henning Scholland wrote:
 Am 30.07.2014 um 17:56 schrieb Martin Koppenhoefer:
  Die offiziellen haben aber den Vorteil, dass sie ausgeschildert
  sind, gilt das für die radweit Wege denn auch?
 
 Wobei diese Ausschilderung häufiger zu wünschen übrig lässt. Wenn man
 so konsequent an die Sache ran geht, müsste man dann nicht auch
 Wegabschnitte der Radrouten aus der Relation wieder raus nehmen, wenn
 das Schild gerade mal weg ist?

Der Vergleich hinkt, weil hier nur die Pflege der Route schlecht
ist, aber eine Ausschilderung zumindest angedacht ist. Das ist
als wenn du vorschlägst, Strassennamen zu löschen, weil ein LKW
mal wieder das Strassenschild umgefahren hat.

 Mir ist da die Karte der Radweitstrecken deutlich lieber und in meinen
 Augen auch deutlich einfacher nachzuvollziehen.

Ob die Routen gut oder schlecht sind ist aber eben kein
entscheidendes Kriterium, ob sie in OSM aufgenommen werden sollten.
Wenn wir damit anfangen, werden wir ganz schnell duzende private
Routennetze in OSM haben, weil es immer jemanden geben wird, der
das eine oder andere gut findet.

Gruss

Sarah

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

Re: [Talk-de] Radweit (War: Was tu, wenn ein user permanent Daten zerstört?)

[Sarah Hoffmann]

On Thu, Jul 31, 2014 at 10:08:32PM +0200, Henning Scholland wrote:
 Am 31.07.2014 um 20:52 schrieb Sarah Hoffmann:
  Einen gewissen offiziellen Charakter sollten Routen, die in OSM 
  eingetragen werden schon haben. Und für Deutschland heisst das 
  meiner Meinung nach schon, dass sie ausgeschildert sind. Ich 
  persönlich find es sogar schon grenzwertig, wenn irgendwelche 
  Stadtrundgänge oder Wanderrouten auftauchen, die zwar vom lokalen 
  Touristenverein empfohlen sind, aber dann nur auf einem Faltblatt 
  oder im Internet beschrieben und nicht ausgeschildert.
 
 Da gibt es aber diverse Probleme. Was ist denn offiziell? Ist es
 offiziell, wenn der örtliche Nordic Walking-Treff drei Wege um den Ort
 mit Aufklebern verziert? Was wenn die Aufkleber dann nach und nach
 verblassen und unkenntlich sind?

Wenn sie das ein bisschen pflegen, fände ich das offiziell genug. Es gibt
da sicherlich eine weite Grauzone, wo man sich streiten kann. Aber hier 
geht die Diskussion ja um Radweit.

Also: sobald ulemm seine Fernradrouten durchgehend mit Aufklebern verziert 
und das auch pflegt, dann können wir diskutieren, ob es nicht Sinn macht,
die Routen aufzunehmen. Solange sie nur auf seiner privaten Website 
existieren, ist der Fall aber glasklar: sie gehören nicht in OSM.

Sarah

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

Re: [Talk-de] Rad-Wander-Skate-Routen

[Sarah Hoffmann]

On Fri, May 23, 2014 at 02:50:47PM -0700, NopMap wrote:
 Thorsten Nau wrote
  ich würde je Fortbewegungsart eine separate route-Relation erstellen. 
 
 +1
 
 Eine dedizierte Relation pro Route ist IMHO die einzig vernünftige Lösung,
 auch wenn die Routen für verschiedene Modi zufällig auf dem gleichen
 physikalischen Weg liegen.

Es geht hier nicht um überlappende Routen, die gehören selbstverständlich
in verschiedene Relationen. Es geht um eine Route, die von Anfang an
für verschieden Modi konzipiert und auch ausgewiesen ist. In Europa
findet man sowas relativ selten, aber in Amerika sind solche
Multi-Use-Routen weiter verbreitet, besonders wohl auf ehemaligen
Bahnstrecken. Die Relation zu duplizieren bildet sowas meiner
Meinung nach ungenügend ab.

Sarah

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

Re: [Talk-de] Rad-Wander-Skate-Routen

[Sarah Hoffmann]

Hi,

On Thu, May 22, 2014 at 01:51:45PM +0200, C.Brause wrote:
 Mein Ansatz wäre jetzt, die Route als Relation mit
 route=bicycle;hiking;inline_skates zu bezeichnen und den mir bekannten
 Renderern (opencyclemap und waymarks) den Hinweis geben, dass solche
 Wege auch aufgenommen werden könnten/sollten.
 
 Ein Blick auf Taginfo zeigt mir, dass solche Kombinationen insgesamt ca.
 110 mal vorkommen. Gefunden habe ich aber auch Radrouten, bei denen die
 Zusatzinfo, dass es sich auch um eine Ausgewiesene Rundstrecke für
 Skater und Wanderer handelt, in description=* befindet. Zum Auswerten
 ist das natürlich kaum geeignet. Ich vermute, dass das so gelöst wurde,
 damit es wenigstens irgendwo auch zu sehen ist.
 
 Im Wiki findet sich nichts zu Routen, die für mehr als ein
 Fortbewegungsmittel ausgeschildert sind.
 
 Was haltet ihr von dem Semicolonansatz und dem Anschreiben der Renderer?

waymarkedtrails.org unterstützt den Semikolonansatz seit ein paar Wochen, 
weil ich gefunden habe, dass das a) die Wirklichkeit am genausten abbildet
und b) für die Mapper so am einfachsten zu warten ist.

Gruss

Sarah

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

Re: [OSRM-talk] Foot profile

[Sarah Hoffmann]

On Fri, May 02, 2014 at 11:48:56AM +0200, Emmanuel Bégué wrote:
 Hello,
 
 I'm trying to use foot.lua from cbf-routing-profiles
 direct link:
 https://github.com/sosm/cbf-routing-profiles/blob/master/foot.lua

That's an old unmaintained one which really should be removed. 
Please try one of those two:

https://github.com/sosm/cbf-routing-profiles/blob/master/foot-city.lua
https://github.com/sosm/cbf-routing-profiles/blob/master/foot-hiking.lua

They work fine against OSRM versions 0.3.3 - 0.3.9.

 Then I tried to remove the four first lines require... from
 foot.lua, as no require is used in current profiles (and car.lua even
 says in a comment function temporarily inlined).

Those requires are necessecary. The library files can be
found in lib/ and you need to supply the directory path
to osrm-extract and osrm-prepare, like that:

LUA_PATH=$scriptdir/lib/?.lua ./osrm-extract other options

see https://github.com/sosm/cbf-routing-profiles/blob/master/compile_profiles.sh
for how those profiles are used with OSRM in
osm.ch's production environment.

 Is this syntax documented? Or, how does one write a profile from
 scratch? (Or at least, how does one read a profile?)
 
 (I would be happy to recursively test little modifications to existing
 profiles, but since extract/prepare takes a long time, it doesn't seem
 like a practical solution...)

That's what I did. Use a smaller extract for testing and it
works ok.

Cheers

Sarah

 On Tue, Apr 29, 2014 at 10:16 PM, Emmanuel Bégué medu...@gmail.com wrote:
  On Tue, Apr 29, 2014 at 8:36 PM, Sarah Hoffmann lon...@denofr.de wrote:
 
  We have adapted foot profiles on our Swiss installation[1], which seem
  to work fairly ok. Code is here:
  https://github.com/sosm/cbf-routing-profiles
 
  Thanks!! I'll give it a try ;-)
 
  Regards,
  EB
 
 ___
 OSRM-talk mailing list
 OSRM-talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/osrm-talk

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

Re: [OSRM-talk] Foot profile

[Sarah Hoffmann]

On Tue, Apr 29, 2014 at 07:18:34PM +0200, Emmanuel Bégué wrote:
 Thanks for a prompt reply, but how would poor data quality explain the
 fact that two points that are very very near one another result in
 such a different outcome?
 
 Where can I find more information in how to write profiles?
 
 And, in your experience, would a car profile that would basically
 accept to take any road, and ignore road directions, be an acceptable
 approximation for a foot profile?

We have adapted foot profiles on our Swiss installation[1], which seem
to work fairly ok. Code is here:

https://github.com/sosm/cbf-routing-profiles

(foot-city.lua for 'city walking', i.e. shorter route,
 foot-hiking.lua for 'hiking', i.e. less asphalt, quieter roads)

Main gotcha: the profile misuses speed to get appropriate route
preferences. The frontend therefore ignores the times it gets from
OSRM and simply computes its own using the distance and a fixed speed.

Cheers

Sarah

[1] http://routing.osm.ch

 On Tue, Apr 29, 2014 at 6:47 PM, Dennis Luxen i...@project-osrm.org wrote:
  Salut Emmanuel,
 
  the foot profile is the least maintained. And foot data is among the most 
  inconsistent tagged data in OSM. You routing data probably broke into many, 
  many unconnected pieces.
 
  —Dennis
 
 
  Am 29.04.2014 um 18:29 schrieb Emmanuel Bégué medu...@gmail.com:
 
  Hello,
 
  Trying to use Project-OSRM for directions by foot, it seems some
  points simply don't work, either as start or stop points, whereas
  points that are very near, work fine (as well as some points that
  shouldn't be reachable because for example they're in the water).
 
  For example the point 48.88368971897955,2.332395315170288 (north of
  Paris), used as a start or an end point, always results in 207,
  Cannot find route between points.
 
  But if we use instead 48.88371088449246,2.332277297973633 (a few
  meters away) then everything's fine; or if we use the offending point
  with a car profile on Project-OSRM demo site: no problem.
 
  No problem either if we begin or end our journey in the middle of a
  river: 48.85939286077621,2.331901788711548, so it's clearly not the
  case that the destination point is somehow unreachable by foot.
 
  I have tried to set the offending point to the nearest node with
  locate but that didn't help:
 locate?48.88368971897955,2.332395315170288 = 48.883674,2.332385
  -- but that last point doesn't work any better.
 
  How can I investigate this? (How do we ask Project-OSRM to print more
  elaborate error messages?)
 
  I'm using Project-OSRM version before 3.9, the stock foot.lua
  profile and OSM data for France from Geofabrik.
 
  Thanks for any pointer.
 
  Regards,
  EB
 
  ___
  OSRM-talk mailing list
  OSRM-talk@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/osrm-talk
 
 
  ___
  OSRM-talk mailing list
  OSRM-talk@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/osrm-talk
 
 ___
 OSRM-talk mailing list
 OSRM-talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/osrm-talk

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

Re: [OSM-talk] No new information on the SOTM since January 2014

[Sarah Hoffmann]

Hi all,

On Sat, Apr 05, 2014 at 12:57:09PM -0700, Steve Coast wrote:
 Why don’t we focus on the substance raised, [...]

Indeed. I believe the topic of this thread was the currernt state of 
planning of SOTM 2014. It would be great if somebody directly
involved in the organization of the conference could give a short
statement about the state of things.

Otherwise, if there are general concerns over the mission and organization
of OSMF or the current behaviour of the board, please open 
a new thread with a new topic, preferably on osmf-talk@ which is
better suited for this kind of discussion.

Thank you kindly

Sarah

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

Re: [Talk-de] Postalische Bezeichnung (addr:place -)

[Sarah Hoffmann]

Hi,

On Sun, Mar 30, 2014 at 07:55:06PM +0200, fly wrote:
 On 30.03.2014 19:06, Sarah Hoffmann wrote:
  On Sun, Mar 30, 2014 at 04:16:47PM +0200, fly wrote:
  Nein, es gibt keinen place= mit dem Namen Außenbezirk. Es ist nur ein
  postalischer Zusatz, der anstatt Straße verwendet wird. Eventuell haben
  die Höfe auch noch einen eigenen Namen, welcher aber nicht in die
  Adresse aufgenommen wurde.
  Somit ist addr:place wohl eher fehl am Platz.
 
  Wie gesagt have ich mich erstmal für addr:street entschieden, auch wenn
  es ein Taggen für Software ist.
  
  Wenn ich deine Beschreibung richtig verstehe, dann kann 'die Software'
  aber mit deinem Tagging auch nichts anfangen, es sei denn, du hast
  gleich zweimal absichtlich falsch getaggt und irgendwo einer Strasse
  einen Namen gegeben, den sie nicht hat. 
 
 Hätte nicht gedacht, das Nominatim eine passende Straße brauch um die
 Adresse vollständig anzuzeigen.

Das ist eine interne Optimierung, weil man nicht einen Suchindex
über Billionen von Addressen anlegen will. Also sucht man erstmal
die Strasse und schaut dann, ob es auch eine passende Hausnummer
dazu gibt.

Die Sache mit addr:street vs. addr:place hat aber damit erstmal
nichts zu tun. Das ist entstanden, weil man vor langer Zeit mal
gesagt hat, dass man einfach nur addr:housenumber taggen kann
und dann wird angenommen, dass die Hausnummer zur nächstgelegen
Strasse gehört. Als man dann 'entdeckt' hat, dass es auch Adressen
ohne Strassenangabe gibt, bekam man dann Schwierigkeiten, weil es
eben nicht einfach addr:street weglassen konnte. Deshalb also
addr:place, was im Prinzip ausssagt, dass diese Adresse eben
nicht einer Strasse zugeordnet werden soll, sondern dass die
Hausnummer zu der und der Ortsbezeichnung gehört.

  Aber es wäre einfach mal interessant, das konkrete Beispiel zu sehen.
 
 https://www.openstreetmap.org/relation/3220946 bzw.
 https://www.openstreetmap.org/way/111871290

Interessant. Wie erwartet, macht Nominatim eine Strassenaddresse
draus:

http://nominatim.osm.org/details.php?osmtype=Wosmid=111871290

 Allerdings gebe ich Martin K. recht , dass dies eher ein Fall für
 addr:full ist und werde es bald auch so eintragen.
 Wird addr:full denn überhaupt von gängiger Software ünterstützt ?

addr:full ist auf der Todo-Liste, funktioneriert aber zur Zeit noch nicht.
Allerdings würde ich in dem Fall schon eher addr:place verwenden,
weil es ja genau die Situation ist, dass die Adresse keiner Strasse
zugeordnet wird. Nominatim wird es dann immernoch nicht richtig machen,
weil er auch für eine addr:place-Adresse ein existierendes Objekt
erwartet, aber das ist ja dann eher ein Software-Fehler, den man fixen
kann. Müsste man mal überlegen, wie man das am besten macht.

addr:full würde ich eher für Adressen verwenden, die in gar kein
Schema passen, also sowas wie 'das dritte Haus hinter der ehemaligen
Tankstelle'. Soll es ja geben als offizielle Addresse.

Gruss

Sarah

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

Re: [Talk-de] Postalische Bezeichnung (addr:place -)

[Sarah Hoffmann]

Hi,

On Sun, Mar 30, 2014 at 04:16:47PM +0200, fly wrote:
 Nein, es gibt keinen place= mit dem Namen Außenbezirk. Es ist nur ein
 postalischer Zusatz, der anstatt Straße verwendet wird. Eventuell haben
 die Höfe auch noch einen eigenen Namen, welcher aber nicht in die
 Adresse aufgenommen wurde.
 Somit ist addr:place wohl eher fehl am Platz.
 
 Sobald addr:street keinen direkten Bezug auf eine Straße sondern nur
 noch die entsprechende Zeile der Adresse darstellt könnten wir sogar auf
 addr:place verzichten. Solange es aber einen direkten Bezug geben soll,
 brauche ich wohl eher einen neuen Tag (ob allgemein für die
 entsprechende Zeile in der Anschrift oder bestimmt für diese
 Gegebenheit, ist erstmal zweitrangig).
 
 Wie gesagt have ich mich erstmal für addr:street entschieden, auch wenn
 es ein Taggen für Software ist.

Wenn ich deine Beschreibung richtig verstehe, dann kann 'die Software'
aber mit deinem Tagging auch nichts anfangen, es sei denn, du hast
gleich zweimal absichtlich falsch getaggt und irgendwo einer Strasse
einen Namen gegeben, den sie nicht hat. 

Aber es wäre einfach mal interessant, das konkrete Beispiel zu sehen.

Gruss

Sarah

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

Re: [OSM-talk] Nominatim

[Sarah Hoffmann]

On Sat, Feb 15, 2014 at 04:43:15PM -0800, Clifford Snow wrote:
 When searching for a point of interest, such as Guild 45th Theatre in
 Seattle, Nominatim return the following:
 Cinema Guild 45th Theatre, North 45th Street, Fremont, Wallingford,
 Seattle, King, Washington, 98103, United States of America.
 But the POI is also contained within a building outline with an address.
 Yet Nominatim does not return the building address.
 
 Wouldn't it be nice if Nominatim also returned the address if it is within
 a building outline with address tags and didn't contain address tags? For
 example it could look something like:
 Cinema Guild 45th Theatre, 2215, North 45th Street, Fremont,
 Wallingford, Seattle, King, Washington, 98103, United States of America.
 This would be nice for people looking for the address of the establishment.

It's something that is on the todo list.

Sarah

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Sarah Hoffmann]

On Fri, Feb 07, 2014 at 03:01:58PM +0100, hike39 wrote:
 ich nutze für die Planung meiner Wanderungen QLandkarteGT. Tolles
 Produkt, das die ganze Zeit wunderbar funktioniert hat. Nun mußte ich
 gestern feststellen, dass die OSM Kacheln nicht mehr angezeigt werden.
 
 In dem Forum von QLandkarteGT mußte ich dann feststellen, dass ich nicht
 der einzige bin, der dies festgestellt hat. Eine Nachfrage ergab dann
 den Hinweis, dass die Mapnik Administration das Abrufen der Tiles durch
 QLandkarteGt abblockt.
 
 Christoph Bledl schrieb:
  But the strength they (the mapnik tile administrators) enforce their
  policy. qlandkartegt, at least in some versions, is currently blocked
  there.
  ...
  My longer statement not everybody agrees with can be found here:
 http://article.gmane.org/gmane.comp.gis.qlandkartegt.user/1340

Wie diese Mail richtig beschreibt, wurde nicht QLandkarteGT speziell
geblockt, sondern alle Requests, die keinen oder einen gefakten
User-Agent geliefert haben. Diese Requests stammen hauptsächlich
von Tile-Scrapern und machen einen grossen Teil der Last aus.
Nötig geworden war das Sperren, weil die Server wegen Hardware-Problemen
nicht die volle Last fahren konnten und der Service aber für die
Website erhalten bleiben sollte. QLandkarteGT war da wohl eher
Kolleteralschaden, an dem es aber selbst schuld war, weil es sich
eben nicht an die Nutzungsbedingungen gehalten und einen vernüftigen
User-Agent geschickt hat. 

Wirklich traurig ist, das die Entwickler von QLandkarteQT
es vorziehen, die Situation zu verschlimmern, indem sie von einem
etwas wengier gefakten zu einem mehr gefakten User-Agent wechseln. 
An deiner Stelle würde ich mich nach einer Alternative umsehen.

 Was ist Eure Meinung hierzu. Muss man demnächst damit rechnen, dass
 OSMAnd, OSMPad, Locus und wie die Apps alles heissen auch blockiert werden?

Das kann durchaus passieren. Die Kapazität der OSM-Server ist nun 
mal begrenzt und obwohl sich die Admins bemühen, das beste aus
der bestehenden Hardware herauszuholen, gibt es einfach Grenzen.
Das massenhafte Herunterladen von Tiles für die Offline-Nutzung 
wurde noch nie gerne gesehen, weil es eine Menge unnötige Last
erzeugt, und sollte es wieder zu Engpässen auf dem Server kommen,
müssen weitere Scraper damit rechnen, gesperrt zu werden.

Zum Glück bieten ja wenigstens einige der Apps gute Offline-Vektordaten
an, mit denen man böse Überraschungen verhindern kann.

Gruss

Sarah

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

Re: [Talk-de] Exportfunktion auf der OpenStreetMap.org Seite

[Sarah Hoffmann]

On Mon, Feb 03, 2014 at 02:01:55PM +0100, Martin Koppenhoefer wrote:
 Am 3. Februar 2014 12:06 schrieb Georg Feddern o...@bavarianmallet.de:
 
  Wäre es dann nicht evtl. sinnvoll, beim Aufruf von Teilen auch gleich
  auf die Standard-Ebene zu wechseln?
 
 kannst Du ja mal vorschlagen (trac oder github) und sehen, wie die
 Zuständigen dazu stehen, denkbar wäre das sicherlich.

Das wäre auch nicht das richtige Verhalten, weil im gleichen 'Teilen'-
Menü ja auch Links auf die Karte generiert werden können. Und diese
Links beachten den aktuell eingestellten Kartenstil durchaus, zumindest
beim langen Link.

Sarah

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

Re: [Talk-de] zum neuen OSM - Design

[Sarah Hoffmann]

Hi,

On Tue, Dec 10, 2013 at 09:26:16PM +0100, Andre Hinrichs wrote:
 Mir ist jedoch gerade heute aufgefallen, dass es scheinbar den Rahmen
 nicht mehr gibt. Früher konnte man mit den Anhang box=yes einen schönen
 Rahmen zeichnen. Hier ein Beispiel
 http://www.openstreetmap.org/?minlon=10.29minlat=52.11maxlon=10.90maxlat=52.50box=yes
 wie es früher funktionierte. Das geht jetzt leider nicht mehr. Bekomme
 ich den Rahmen irgendwie wieder? Oder ist der auf Dauer wegoptimiert?
 Ich habe den häufig benutzt, um den Download-Bereich für meine selbst
 erzeugten Garmin-Karten zu wählen.

Das war undokumentierter Parameter, der mit dem Redesign weggefallen ist und
auch definitiv nicht zurückkommen wird. Die Diskussion dazu in der vollen
Länge gibt es im entsprechenden Trac-Ticket: 
https://trac.openstreetmap.org/ticket/5050

Ich empfehle, mal in umap reinzuschauen: http://umap.openstreetmap.fr/de/

Gruss

Sarah

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

Re: [Talk-de] zum neuen OSM - Design

[Sarah Hoffmann]

On Tue, Dec 10, 2013 at 10:32:59PM +0100, Frederik Ramm wrote:
 On 10.12.2013 21:26, Andre Hinrichs wrote:
  Bei mir erscheint auch jedes Mal die Willkommen-Meldung, die ich
  dann wegklicken muss; das nervt auf die Dauer.
 
 Dazu gibts zwei Meinungen. Die eine ist die haben das verbockt, jetzt
 sollen die das auch fixen. Die andere ist hilf Dir selbst und fuehrt
 ueber dieses Greasemonkey-Skript:
 
 
 // ==UserScript==
 // @name Remove OSM welcome box
 // @include  http://www.openstreetmap.org/*
 // ==/UserScript==
 
 var welcome = $(div.welcome);
 if (welcome) welcome.remove ();
 
 
 Natuerlich kann man auch einfach einen Login-Cookie haben.

Das geht inzwischen auch ohne Login mit dem ganz normalen Cookie.
Man muss natürlich erlauben, dass er die Cookies über die Sitzung
hinaus speichern darf. Aber dann sollte die Meldung eigentlich 
wegbleiben, wenn sie einmal weggeklickt wurde.

Sarah

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

Re: [Talk-de] zum neuen OSM - Design

[Sarah Hoffmann]

On Sun, Dec 08, 2013 at 11:34:13AM -0800, NopMap wrote:
 Die History für Node 273510436 gibt einem in dieser Darstellung über 60
 (!!!) Seiten zum Runterscrollen.
 
 Gibt's irgendwo noch eine andere, sinnvollere Sicht auf die History von
 Elementen?

Zum Versionsvergleich kann man das hier empfehlen: http://osm.mapki.com/history/

Gruss

Sarah

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

Re: [Talk-de] Mannheim - Quadratenamen in Mapnik verschwunden

[Sarah Hoffmann]

On Mon, Nov 11, 2013 at 03:25:50PM +0100, Martin Koppenhoefer wrote:
 Am 11. November 2013 15:19 schrieb Theodin theo...@posteo.de:
 
  Hi allerseits,
 
  addr:block wäre korrekt, da es hier um die Adresse geht:
 
  Manuela Mustermann
  F5, 13
  12345 Mannheim
 
 
 
 Wenn Ihr das so taggt, sollte der Name schon heute wieder auf der Karte
 gerendert werden (sofern kein place-tag zusätzlich drauf ist). Ist aber nur
 ein Nebeneffekt dessen, dass alle Flächen beschriftet werden (zumindest
 noch derzeit, soweit ich weiss, Andy will das aber wohl mittelfristig
 ändern). Wenn das alles so getaggt ist, wird ggf. auch die Karte eine extra
 Regel für diese Art von Adressen einführen (genau weiss man das natürlich
 nicht, aber wenn genug Leute anfragen ;-) ).
 
 place=neighbourhood halte ich allgemein für keinen guten tag für diese
 Vierecke bzw. Blöcke, insbesondere, als place mit name ein tag für
 Toponyme ist, und A oder D sind doch keine Ortsnamen, oder?

Die Blöcke sind aktuell so getaggt, weil dann Nominatim die Addressen
richtig auflöst (via addr:place bei der Hausnummer). Kann man sich
jetzt streiten, ob das gut oder schlecht ist, aber wenn ihr das 
schon ändern wollt, würde ich eher vorschlagen, das in das bestehende
Schema einzubauen. Das heisst, die Addressen taggen mit:

addr:housenumber=13
addr:place=F5  (oder addr:block, wenn es nun gar nicht anders geht)

und dann den Block mit

place=block (oder vielleicht city_block)
name=F5

Block-Address-Schemata gibt es übrigens auch in einigen anderen Ecken der 
Welt. Die Japaner hatten letztens mal eine RFC:
https://lists.openstreetmap.org/pipermail/tagging/2013-September/014867.html
Ich finde deren Vorschlag auch nicht optimal (eben weil er auch
wieder eine Sonderbehandlung braucht), aber vielleicht könnte man
sich mal zusammentun und etwas einheitliches entwickeln.

Gruss

Sarah

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

Re: [Talk-de] nominatim und Kreisfreie Städte

[Sarah Hoffmann]

On Wed, Nov 06, 2013 at 09:16:25AM +0100, Florian Lohoff wrote:
 On Tue, Nov 05, 2013 at 06:47:28PM +0100, Martin Koppenhoefer wrote:
  Am 5. November 2013 16:13 schrieb Florian Lohoff f...@zz.de:
  
   In meinem kleinen Weltbild muesste da auf dem boundary ein
   admin_level=6;8 drauf - oder die relation gedoppelt (Wenn man noch
   so Amtliche Gemeindeschluessel hat die Kreis und Stadt unterschiedlich
   sind etc)
  
  +1, ich bin auch dafür, mehrere Relationen zu haben, wenn eine Einheit
  mehrere Level abdeckt, d.h. z.B. eine für Kreis, eine für Stadt. Wie man
  dann auf die Schnelle erkennt, dass die beiden wiederum dasselbe sind,
  weiss ich nicht, durch räumliche Analyse wäre es sicherlich möglich. Oder
  man macht nochmal ne Relation, um die beiden zusammenzubringen? ;-)
 
 Den Vorschlag der auf tagging kam find ich beim ersten nachdenken nicht
 dumm.
 
 Eine Multipolygon relation die die Grenze zusammenhaelt und ansonsten
 nichts beinhaltet.
 
 Dann hat diese Relation wiederum andere relations (Mangels anderem
 schönen objekt) als member die den admin level beinhalten und andere
 Metainformationen.

Verschachtelte Relationen ist etwas, was osm2pgsql nicht kann und
wo auch keine Implementierung in Sicht ist. Da sieht es also eher
schlecht aus mit einer Unterstützung durch Nominatim.

Sarah

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

Re: [Talk-de] nominatim incremental updates Was: nominatim json results Was: nominatim und Kreisfreie Städte

[Sarah Hoffmann]

On Wed, Nov 06, 2013 at 10:32:57AM +0100, Florian Lohoff wrote:
 On Tue, Nov 05, 2013 at 06:39:22PM +, Sarah Hoffmann wrote:
   D.h. addr:postcode wird ignoriert sondern es werden die plz polygone
   verwendet?
  
  Beim Erstimport letztes Jahr wurden PLZ-Centroiden aus den damals 
  vorhandenen 
  addr:postcode-Tags berechnet. Das ist so ziemlich alles, was verwendet wird.
 
 Ich prokel da ja gerade ein bischen rum - Hatte eine Adresse da fehlte
 die Straße - addr:* war auf den Buildings vollständig drauf. 
 
 http://www.openstreetmap.org/browse/way/242237169
 
 Dann habe ich die Straße hinzugefuegt - Leider wird die Adresse nicht 
 gefunden,
 nur die Straße.
 
 Ist das ein indexing Problem was nur durch reimport gelöst werden kann (Oder 
 durch
 update der Building outlines). Scheint als stoße hier das inkrementelle 
 ändern 
 an seine Grenzen.
 
 Oder bin ich wie immer nur zu ungeduldig? 

Da vergisst der Update-Prozess ein Reindexing für die Gebäude anzustossen.
Ich denke, dass könnte man einbauen, schreib mal einen Bugreport.

Ist das übringes nicht ein klassischer Fall für addr:place? Es sieht
so aus, als wenn die Strassen da eigentlich keinen Namen haben und die
Adresse sich auf die Siedlung bezieht.

Gruss

Sarah

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

Re: [Talk-de] nominatim und Kreisfreie Städte

[Sarah Hoffmann]

Hi,

On Tue, Nov 05, 2013 at 02:36:20PM +0100, Florian Lohoff wrote:
  Kreisfreie Städte sind in Deutschland leider irgendwo zwischen
  level 6 und 8.
  http://wiki.openstreetmap.org/wiki/File:Administrative_Gliederung_Deutschlands_admin_level.png
  http://wiki.openstreetmap.org/wiki/DE:Tag:boundary%3Dadministrative
 
 Schon klar - Eigentlich sind sie beides denn Administrativ uebernehmen
 Kreisfreie Städte sowohl die Administrativen Tätigkeiten der Kreise wie
 auch der Kommunen. Deshalb wäre ja der Ansatz das die Boundary sowohl 
 level 6 wie auch level 8 ist.

Leider ist es aber so zur Zeit nicht gemappt. Zur Zeit haben wir
nur boundaries mit admin_level=6 in der Datenbank und es gibt
praktisch keine Möglichkeit zwischen echten Kreisen und kreisfreien 
Städten zu unterscheiden.

  Ich kann verstehen wenn Nominatim mangels einer weiteren relation
  level=8 (city) nur den level=6 (county) zurückgibt. Die gleiche
  Relation nochmal in den city Wert zurückzugeben finde ich macht
  wenig Sinn. Oder geht es darum, dass beim geocoden das Feld 'city'
  nie leer sein sollte?
 
 Genau - Sonst faengt jeder an die nominatim resultate mit code
 aufzupimpen um das Ergebniss bewerten zu koennen.

Ich täte Nominatim diesbezüglich gerne verbessern, aber was es
dafür ersteinmal braucht, ist ein einheitliches Taggingschema
für das Problem boundary erstreckt sich über mehrere admin_levels.
Ich bin entschieden gegen soetwas wie 'de:place' weil das Problem
allgemein genug ist, dass es keine Sonderregelung für Deutschland
braucht.

Falls also jemand mal Lust hat, dass ganze auf tagging@ zur Sprache
zu bringen und es da dann eine Einigung gibt, könnte man das auch
irgendwie Nominatim beibringen.

 Ich versuche gerade herauszufinden in wieweit man den nominatim
 Ergebnissen trauen kann - D.h. wie bewerte ich ob die vollstaendige
 und richtige Adresse gefunden wurde.
 
 Die importance die zurueckgeliefert wird ist so weit ich das sehe
 eher unbrauchbar. Bei vollstaendigen Adressen wie oben schwankt die
 zwischen 0.600 und 1.1 - Und ob eine Hausnummer und vor allem
 die abgefragt Hausnummer wirklich gefunden wurde sieht man da nicht.

Importance macht nur wirklich Sinn bei Objekten für die es einen
Wikipedia-Eintrag gibt, also eher oberhalb vom Strassen-Level.

Wenn du wissen willst, ob die Hausnummer gefunden wurde oder nur
die Strasse, empfehle ich place_rank zu parsen. Hausnummern haben
Rank 30, Strassen Rank 26 oder 27. Eine vollständige Liste der
Ranks ist hier:
http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview#Indexing.2Faddress_calculation

Gruss

Sarah

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

Re: [Talk-de] nominatim und Kreisfreie Städte

[Sarah Hoffmann]

On Tue, Nov 05, 2013 at 04:13:33PM +0100, Florian Lohoff wrote:
 Wo finde ich den denn?!? Ich finde noch ein type und class. Die sind 
 type=house
 class=place bei gefundenen Adressen sehe ich gerade. Das reicht mir so weit
 weil ich eh nur mit exakt gefundenen Adressen was anfangen kann.
 
 $ wget -O - -q 
 'http://nominatim.openstreetmap.org/?q=Dachsweg+2%2C+53125+Bonnformat=jsonaddressdetails=1'
  | perl -e 'use JSON; use Data::Dumper; print Dumper(decode_json(STDIN));'

Versuche es mal mit format=jsonv2.

Ich könnte schwören, es stand mal in der Doku, dass es verschiedene
json-Formate gibt. Habe es jetzt wieder angefügt. Der Hauptunterschied
zwischen beiden Formaten ist dass class in jsonv2 durch category 
ersetzt wurde.

Ich schreibe auch mal auf die Todo-Liste, place_rank im json-Format
zu exportieren.

Gruss

Sarah



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

Re: [Talk-de] nominatim json results Was: nominatim und Kreisfreie Städte

[Sarah Hoffmann]

On Tue, Nov 05, 2013 at 05:10:48PM +0100, Florian Lohoff wrote:
 Ich habe gerade noch einen gefunden:
 
   Landwehr 8, 46569 Hünxe 
 
 gibt den Track Landwehr
 
   Landwehr 8a, 46569 Hünxe
   
 gibt nix zurueck.

Hier ist nicht die Hausnummer das Problem, sondern die PLZ. Nominatim
hat die so nicht drin und kann PLZs auch nicht ignorieren. Dass die
erste Anfrage funktioniert, liegt an einem anderen Bug, sollte also
eigentlich auch nicht gehen.

Ich kann nur empfehlen, PLZs bei der Adresssuche möglichst wegzulassen.
Die PLZs in Nominatim sind unvollständig und veraltet (Stand Sept. 2012).
Das zu fixen ist ganz oben auf der Todo-Liste, was aber im Augenblick
nicht viel bedeutet.

Gruss

Sarah

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