Re: [OSRM-talk] New v5.23.0 release

[Michael Bell]

I've had a go at reverting the breaking change:
https://github.com/Project-OSRM/osrm-backend/pull/5860
I was able to compile libosrmc against it.

Michael

On Thu, 15 Oct 2020 at 17:14, Denis Chapligin  wrote:
>
> IIRC you had some idea of hiding that change and unbreaking the API by 
> templating ResultT type. If you can explain your idea I can probably 
> implement it.
>
> чт, 15 окт. 2020 г. в 17:43, Daniel Patterson via OSRM-talk 
> :
>>
>> Dammit, sorry Julien, I'd forgotten about that issue - I'm not using the 
>> libosrm bindings directly, so this change slipped my mind.
>>
>> If someone has time to fix the interface, we can release 5.24.0 to address 
>> it, and mark 5.23.0 as a dud.  The interface change clearly breaks semver 
>> rules as it's not backward compatible.  The alternative would be to release 
>> OSRM 6.0.0, but this feels like much too small a change to justify doing 
>> that.
>>
>> While I managed to find time to work through the release process, I do not 
>> have time to do any significant refactoring work :-/
>>
>> daniel
>>
>> On Thu, Oct 15, 2020 at 12:38 AM Julien Coupey  wrote:
>>>
>>> Hi Daniel and all
>>>
>>> Thanks for your work on this release, and all the various recent
>>> contributions that made it possible. It's great to see a new OSRM
>>> version, first one in a long time!
>>>
>>> I'd like to ask for a clarification though, if possible, on the status
>>> of libosrm regarding this new version and possible future ones. There
>>> are a couple of reports about the API breaking changes ([1] and [2]). It
>>> means that projects relying on libosrm v5.* no longer compile with
>>> v5.22, and now v5.23. This is a major problem for downstream users and
>>> maintainers, especially since the OSRM release process has long been
>>> adhering to the semver scheme. I only see two ways out:
>>>
>>> 1. The new v5.23 release somehow endorses the API change (after all a
>>> fix now would also be a new change from the last two releases). In which
>>> case downstream users will have to fiddle with adjustments based on
>>> libosrm minor version.
>>>
>>> 2. This is considered as something that must be fixed at some point in
>>> the future. Then no action is required downstream, except stating that
>>> current libosrm versions are no longer compatible until a patch or new
>>> minor version is released.
>>>
>>> Knowing which option is the most likely would definitely help.
>>>
>>> [1] https://github.com/Project-OSRM/osrm-backend/issues/5548
>>> [2] https://github.com/Project-OSRM/osrm-backend/issues/5741
>>>
>>> Regards
>>> Julien
>>>
>>> On 14/10/2020 23:14, Daniel Patterson via OSRM-talk wrote:
>>> > Hello all,
>>> >
>>> >Well, after a long hiatus, I've finally had time to cut a new
>>> > release.  I've bundled up a bunch of the changes that have been
>>> > submitted over the last couple of years, and tagged 5.23.0, and cleaned
>>> > up the changelog/master branch which had been left dangling in an
>>> > unclear state for a while.  Build/publish of the various binaries is
>>> > underway and should be complete soon.  Here's what's changed - mostly
>>> > bugfixes, but a few small features as well.
>>> >
>>> >- Changes from 5.22.0
>>> >  - Build:
>>> >- FIXED: pessimistic calls to std::move
>>> > [#5560](https://github.com/Project-OSRM/osrm-backend/pull/5561)
>>> >  - Features:
>>> >- ADDED: new API parameter - `snapping=any|default` to allow
>>> > snapping to previously unsnappable edges
>>> > [#5361](https://github.com/Project-OSRM/osrm-backend/pull/5361)
>>> >- ADDED: keepalive support to the osrm-routed HTTP server
>>> > [#5518](https://github.com/Project-OSRM/osrm-backend/pull/5518)
>>> >- ADDED: flatbuffers output format support
>>> > [#5513](https://github.com/Project-OSRM/osrm-backend/pull/5513)
>>> >- ADDED: Global 'skip_waypoints' option
>>> > [#5556](https://github.com/Project-OSRM/osrm-backend/pull/5556)
>>> >- FIXED: Install the libosrm_guidance library correctly
>>> > [#5604](https://github.com/Project-OSRM/osrm-backend/pull/5604)
>>> >- FIXED: Http Handler can now deal witch optional whitespace
>>> > between header-key and -value
>>> > [#5606](https://github.com/Project-OSRM/osrm-backend/issues/5606)
>>> >  - Routing:
>>> >- CHANGED: allow routing past `barrier=arch`
>>> > [#5352](https://github.com/Project-OSRM/osrm-backend/pull/5352)
>>> >- CHANGED: default car weight was reduced to 2000 kg.
>>> > [#5371](https://github.com/Project-OSRM/osrm-backend/pull/5371)
>>> >- CHANGED: default car height was reduced to 2 meters.
>>> > [#5389](https://github.com/Project-OSRM/osrm-backend/pull/5389)
>>> >- FIXED: treat `bicycle=use_sidepath` as no access on the tagged
>>> > way. [#5622](https://github.com/Project-OSRM/osrm-backend/pull/5622)
>>> >- FIXED: fix table result when source and destination on same
>>> > one-way segment.
>>> > 

[Talk-transit] How to tag bike rule on transit vehicles?

[Phake Nick]

Different bus/train/ferry/other public transit services could sach have
different policies on whether bicycles can be allowed onboard or not. How
should they be tagged?
Off hand I have think of several types of permission:
- Allowed
- Prior notification needed
- Only during some time period (not allowed during peak hour or holiday
only)
- Specific service frequency only
- Only for frequencies using particular behicle
- Folded bike only
- Only if wheels are removed and packed into cycling bag
- Disallowed
Should they be tagged on individual route related or network relation?
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk] Idea for improving mapping system

[Joseph Eisenberg]

Would you mind describing the proposed system here, in a concise form?

On Sat, Oct 17, 2020 at 7:36 PM TheAdventurer64 <
little.banana.p...@gmail.com> wrote:

> Hello everyone,
>
> A user and I were talking about implementing a system for better mapping,
> as described here:
> https://osmus.slack.com/archives/C029HV951/p1602968516431900
> This addition would have many benefits, including:
> * More mapping. We have tons of new mappers each day, as well as a great
> editor for them. However, many of these new mappers leave after just a few
> edits. Examples:
> https://www.openstreetmap.org/user/lukastheg03
> https://www.openstreetmap.org/user/Th3Roomi3
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Idea for improving mapping system

[TheAdventurer64]

Hello everyone,

A user and I were talking about implementing a system for better mapping,
as described here:
https://osmus.slack.com/archives/C029HV951/p1602968516431900
This addition would have many benefits, including:
* More mapping. We have tons of new mappers each day, as well as a great
editor for them. However, many of these new mappers leave after just a few
edits. Examples:
https://www.openstreetmap.org/user/lukastheg03
https://www.openstreetmap.org/user/Th3Roomi3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Attribution sur water-map.org/

[Philippe Verdy]

Vous pouvez au moins tenir compte de la taille d'affichage de la carte pour
savoir si un petit (i) suffit ou si une attribution normale peut tenir sans
problème.
Cela ne bloque pas ce que va afficher le panneau qui s'ouvre quand on
clique dessus qui peut tout à fait mentionner Mapbox comme fournisseur,
mais ne doit pas oublier de mentionner OSM comme source première (la plus
visible dans tout ça, indépendamment du travail de rendu fait par Mapbox
(ou du travail de qualification et de supervision par Mapbox des données
soumises par leurs utilsiateurs ou les vôtres).
D'ailleurs votre site n'est pas destiné directement à faire de vos
visiteurs des utiliateurs de Mapbox, ce sont avant tout des utilisateurs de
votre appli, et Mapbox n'est qu'un prestataire que vous avez choisi en
privé.

Vous ne demandez pas à vos utilisateurs je pense de se créer un compte et
d'identifer chez Mapbox mais chez OSM: ils sont donc des utilisateurs d'OSM
d'abord avant d'être des utiliqateurs indirects de Mapbox du fait de votre
choix, et même si en tête ce sont d'abord vos utilisateurs que vous voulez
suivre. De fait OSM devrait être placé en tête 'juste en dessous de
vous pour les services spécifiques que vous proposez, et ensuite Mapbox ne
posera aucune problème. A vous donc de revoir ce que va afficher le petit
(i) quand on clique dessous, ou la mention complète normale (si sous avez
la place dans votre interface).

La même chose vaut pour d'autres sites, comme Facebook qui eux aussi
affichent des "minicartes" (non navigables) avec un petit (i) qui peut se
justifier vu la taille et le peu d'informations affichées. Facebook
n'utilise pas qu'OSM d'ailleurs, pour certains services il renvoie chez
Here (est-ce toujours chez Nokia/Microsoft? alors que Microsoft a développé
et déployé une autre solution basée sur Bing et n'a gardé encore qu'une
division sur les smartphones en pleine déconfiture face aux géants coréens,
chinois et Apple).



Le mar. 13 oct. 2020 à 18:39, Water-Map  a écrit :

> Salut Christian,
>
>
>
> Nous tenons énormément à notre collaboration avec OpenStreetMap et nous
> sommes conscients que notre projet n'existerait pas sans ce monde open et
> collaboratif.
>
>
>
> Nous avons parlé d'OpenStreetMap aux Nations Unies, à l'UIT et dans notre
> article dans le Parisien, pas par obligation mais parce que c'est un projet
> auquel nous voulons contribuer et faire vivre.
>
>
>
> Notre app est mobile first, mais sur ordinateur j'ai aucun problème
> d'exploser le "i" sur desktop. Je vais me renseigner à partir du mois de
> novembre.
>
>
>
> Et pour les textes, comme j'ai écrit à Yves, je mettrais avec plaisir un
> peu plus en avance OpenStreetMap.
>
>
>
> Bien à toi,
>
>
>
> Stuart
>
>
>
> PS : Je viens de proposer le thème d'eau potable (fontaines + cafés
> refill) sur Talk GB pour Q2 21. S'ils l'acceptent comme projet, est-ce que
> OSM FR pourrait considérer ce même thème pour un projet du mois ?
>
> On Tue, 13 Oct 2020 at 18:04, Christian Quest 
> wrote:
>
>> Le 13/10/2020 à 17:38, Water-Map a écrit :
>> > Bonjour Christian,
>> >
>> > Je ne m'excuse pas.
>> >
>> > Notre site respecte les règles d'attributions de mon point de vue.
>> >
>> > OpenStreetMap est open data où pas ?
>> >
>> > Bien à toi,
>> >
>> > Stuart
>> >
>>
>> J'ai été trop grognon... désolé.
>>
>> Quand je parle d'excuse, je ne vise personne, même moi je pourrai
>> chercher ce qui peut expliquer, excuser ce qui me semble être un manque.
>>
>> Pour le respect des règles d'attribution, ok, d'un point de vue purement
>> juridique ça peut passer mais est-ce sur ce plan là qu'on doit agir l'un
>> envers l'autre ? Je ne pense pas.
>>
>> Ce que j'ai tenté (très maladroitement) de faire comprendre, c'est que
>> nos projets collaboratifs croisés doivent s'entraider et se valoriser
>> l'un l'autre.
>>
>> L'attribution aujourd'hui ne met pas du tout en valeur OSM, entre le
>> problème du "i" à la Mapbox et le about minimaliste.
>>
>> Avec ce niveau d'attribution et donc de reconnaissance envers les
>> contributeurs OSM et bien je n'ai pas plus envie que ça de promouvoir
>> water-map alors que comme d'autres ici je trouve l'idée très bonne.
>>
>>
>> Quant à la notion d'opendata... il y a un mix entre droits (de
>> réutilisation) et devoirs (attribution, partage à l'identique). Je ne
>> détaille pas plus sur la notion d'opendata qui pour moi est en général
>> équivalente à l'opensource (et unidirectionnel) vs le logiciel libre (et
>> collaboratif), mais on n'a pas de terme pour les données "libres" (à
>> part "données libres"). OSM c'est de la donnée libre et collaborative
>> plus que de l'opendata.
>>
>> --
>> 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] SPAM, Attribution manquante sur Inforoute

[Philippe Verdy]

Je ne peux pas. A cause d'un contributeur politique américain (personnel
diplomatique) qui fait des modifs orientées dans un pays dictatorial.

Le sam. 17 oct. 2020 à 17:25,  a écrit :

> Philippe, merci de commencer à créer la page wiki, les scripts de
> création de VM etc...
>
> Jean-Yvon
>
> Le 16/10/2020 à 23:29, Philippe Verdy - ver...@gmail.com a écrit :
> > Dommage qu'il n'utilisent pas un proxy cache pour les tuiles, c'est
> > directement les tuiles d'OSM.org.
> >
> > C'est vraiment si compliqué d'installer un proxy cache (quitte à
> > restreindre la zone navigable et/ou le niveau de zoom nécessaire pour
> > les infos à afficher dessus, pour que cela ne prenne pas beaucoup de
> > ressources réseau pour les mises à jour du cache du proxy, ni beaucoup
> > d'espace de stockage)?
>
>
> ___
> 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

[Philippe Verdy]

je ne juge personne, je constate jsute que c'est un truc pas fini et il ne
faut pas s'attendre à de bons résultats car les données collectées sont
trop insuffisantes. Le simple fait d'avoir un gros paquet de noeuds
"admin_level=15" infique que c'est un truc jeté là en vrac en attendant,
pour résoudre seulement une toute petite partie des cas, juste à titre de
test pour en mesurer la portée avant de savoir ce qu'on doit en faire.
Mais c'est dommage d'exposer ce truc dans la vue publique pour tout le
monde alors que visiblement ça n'est fait que pour les développeurs.
Cette partie de Niominatim n'est d'ailleurs pas documentée, donc pas
soutenue, elle ne peut être que "provisoire" en attendant de trouver des
solutions et les mettre en oeuvre.

Mais il est clair qu'avec juste de noeuds centroïdes pour ces données
il n'y a pas moyen de gérer ça proprement et le schéma de la base de
données Nominatim va devoir changer, ainsi que les algos de recherche,
classification et calcul de pertinence, qui pour l'instant ne tiennent pas
compte (ne serait-ce que pour indiquer l'importance) de la longueur réelle
(des objets linéaires) ni de la surface réelle (des objets surfaciques). Le
classement ensujite pour la pertinance est largement faussé sur ces objets.
Et en plus un seul noeud ne surffira pas, il faudra aussi une bounding box
(donc admettre deux noeuds séparés du centroïde calculé malgré tout assez
bizarrement pour la position des pseudo-noeuds "'placeid" de Nominatim,
sans tenir compte de la topologie des objets concaves ou morcelés, comme je
l'ai montré pour L'Île-Saint-Denis qui est un exemple type, magré tout
simple mais il y en a de bien plus compliquées et bien plus grands,
notamment à la frontière belgo-néerlandaise et en Espagne).

D'ailleurs Nominatim ne tient pas compte non plus de
l'admin_level réellement tagué (alors qu'il a les données) et on constate
des inversions inattendues entre les niveaux quand il les classe (il semble
faire plus confiance en priorité uniquement aux distances relatives entre
les centroïdes, puis effectue seulement un filtrage pour masquer les objets
"homonymes" (à priorui plus grands et classés après mais selon le mauvais
critère).

Bref c'est le constat: Nominatim n'est pas utilisable pour chercher
correctement les objets non directement liés aux adresses (dont ceux dans
le "vrac" du pseudo-niveau 15 et classés systématiquement e n fin de liste
mais comme s'ils étaient inclus dans les objets classés avant comme de
petits hameaux ou lieux-dits ou des batiments isolés)



Le sam. 17 oct. 2020 à 19:31, Topographe Fou  a
écrit :

> Philippe, comme tous les projets "l'approximation", le "bancale", le
> "n'importe comment" et le "stupide" ne pourront s'améliorer qu'avec des
> humains derrière. Et ces humains, comme tous les humains qu'ils soient de
> Nominatim ou d'ailleurs, méritent mieux comme encouragement (et
> remerciements) que ce que j'ai lu à deux reprises aujourd'hui.  Quand bien
> même le fond serait juste, la forme est juste écoeurante, ce qui gâche tout.
>
> Sans avoir à rentrer dans le code tu peux rédiger un ticket sans ces
> jugements pour apporter ta pierre à l'édifice.
>
> Cordialement
>
> LeTopographeFou
> *De:* ver...@gmail.com
> *Envoyé:* 17 octobre 2020 5:52 PM
> *À:* talk-fr@openstreetmap.org
> *Répondre à:* talk-fr@openstreetmap.org
> *Objet:* Re: [OSM-talk-fr] Nominatim et plan d'eau
>
> En fait Nominatim traite les éléments naturels quels que soit leur taille
> comme des noeuds et leur attribue un admin_level=15 (totalement
> synthétique) pour classer les résultats. Il les considère plus petits que
> les noms de batiments (house_name) auxquels il veut les attacher
> pouyr attribuer une adresse et sinon il cherche un highway.
> Ces éléments naturels sont donc classés n'importe comment.
>
> Et je ne spécule pas du tout sur le fait qu'il crée bel et bien des noeuds
> "place" artificiels, avec un id interne puisque c'est bien ce qu'il affiche
> dans ses résultats. Et peu importe si cela ne correspond à rien et que
> l'attribut synthétique admin_level ne correspond lui aussi à rien du tout.
> La logique est totalement fausse qui conduit à les "rattacher" à d'autres
> objets très éloignés et arbitraires qui n'incluient pourtant même pas du
> tout ces noeuds synthétiques.
>
> C'est une très grossière approximation de Nominatim: on ne peut pas
> réduire ces objets à un simple noeud et Nominatim ne sait pas leur attacher
> plutôt une bounding box pour avoir quelquechose de plus pertinent. Il se
> base juste sur une mesure de distance entre deux noeuds (dont le noeud
> artificiel et un autre noeud arbitraire d'un highway ou d'un vraie relation
> boundary).
>
> C'est très bancale. C'est un gros manque sur quelquechose qu'i n'a pas été
> réellement développé mais laissé en vrac dans une classe fourre-tout
> (pseudo-admin_level=15) en attendant un développement sérieux.
> Tant que ces objets restent assimilable à un noeud et qu'ils sont
> réellement inclus dans une 

Re: [OSM-talk-fr] Nominatim et plan d'eau

[Topographe Fou]

  Philippe, comme tous les projets "l'approximation", le "bancale", le "n'importe comment" et le "stupide" ne pourront s'améliorer qu'avec des humains derrière. Et ces humains, comme tous les humains qu'ils soient de Nominatim ou d'ailleurs, méritent mieux comme encouragement (et remerciements) que ce que j'ai lu à deux reprises aujourd'hui.  Quand bien même le fond serait juste, la forme est juste écoeurante, ce qui gâche tout.Sans avoir à rentrer dans le code tu peux rédiger un ticket sans ces jugements pour apporter ta pierre à l'édifice.Cordialement  LeTopographeFou   De: ver...@gmail.comEnvoyé: 17 octobre 2020 5:52 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Nominatim et plan d'eau  En fait Nominatim traite les éléments naturels quels que soit leur taille comme des noeuds et leur attribue un admin_level=15 (totalement synthétique) pour classer les résultats. Il les considère plus petits que les noms de batiments (house_name) auxquels il veut les attacher pouyr attribuer une adresse et sinon il cherche un highway.Ces éléments naturels sont donc classés n'importe comment.Et je ne spécule pas du tout sur le fait qu'il crée bel et bien des noeuds "place" artificiels, avec un id interne puisque c'est bien ce qu'il affiche dans ses résultats. Et peu importe si cela ne correspond à rien et que l'attribut synthétique admin_level ne correspond lui aussi à rien du tout. La logique est totalement fausse qui conduit à les "rattacher" à d'autres objets très éloignés et arbitraires qui n'incluient pourtant même pas du tout ces noeuds synthétiques.C'est une très grossière approximation de Nominatim: on ne peut pas réduire ces objets à un simple noeud et Nominatim ne sait pas leur attacher plutôt une bounding box pour avoir quelquechose de plus pertinent. Il se base juste sur une mesure de distance entre deux noeuds (dont le noeud artificiel et un autre noeud arbitraire d'un highway ou d'un vraie relation boundary).C'est très bancale. C'est un gros manque sur quelquechose qu'i n'a pas été réellement développé mais laissé en vrac dans une classe fourre-tout (pseudo-admin_level=15) en attendant un développement sérieux.Tant que ces objets restent assimilable à un noeud et qu'ils sont réellement inclus dans une relation admin_level ou assez proche à un highway indexés pour les rendre "routables" (Nominatim n'indexe pas tous les highways, seulement ceux ayant un nom ou un numéro de référence) il va retourner n'importe quoi, c'est le hasard le plus complet en terme de classification, il n'y a strictement rien qui soit alors réellement pertinent.Personellement je pense qu'une première amélioration de Nominatim serait qu'il vire les noeuds "place" synthétiques pour les objets qui ne sont pas des noeuds (objets linéraires et surfaces polygonales/multi-polygonales), et qu'il les remplace au moins par des bounding box, afin de rendre les calculs de pertinence bien meilleurs. Et il devrait le faire au moins pour tous les objets actuellement classés en pseudo-admin_level=15. et sans doute aussi (après tests pour éveluer les effets de bords dans la détermination des adresses) pour les highways (quoique pour eux il vaudrait sans doute mieux qu'il indexe les deux extrémités, à moins que ce soit un chemin fermé ou que ce soit un "polyligne" formant des branches ou un réseau dans une relation assimilable alors à une surface approximée par la boundingbox)Le sam. 17 oct. 2020 à 15:56, Sarah Hoffmann  a écrit :Bonjour,

apropos la question pourquoi un lac s'attache a une rue et prends
son adresse. C'est justement quelque chose qu'il faut revoir et
probablement reviser. L'attachement aux rues marche bien pour les
petits POIs comme boite aux lettres ou des supermarches. Ca marche
meme bien pour un petit pont de village mais ce n'est pas une bonne
idee pour les grandes lacs ou baies.

Quand a toutes les autres speculations, j'ai vraiment pas envie de
les discuter parce qu'ils sont exactement ca: speculations qui ont
rien du tout a voir avec comment Nominatim fonctionne. 

Sarah

On Sat, Oct 17, 2020 at 01:00:36PM +0200, Philippe Verdy wrote:
> Tu ne réponds pas à la question ni au cas évoqué autour de
> l'Île-Saint-Denis.
> 
> En effet strictement rien n'associe ce polygone à la route en tant
> "qu'adresse". C'est stupide comme association surtout pour ce type
> d'élément. De plus c'est Nominatim qui en interne a généré un "place node"
> (avec un ID interne) sur le polygone (il n'y a aucun node dans le polygone).
> 
> En créant ce "place node", c'est là qu'il a cherché stupidement à lui
> donner une adresse et à chercher une route proche. Et c'est là que
> l'approximation 

Re: [OSM-talk-fr] Nominatim et plan d'eau

[Philippe Verdy]

En fait Nominatim traite les éléments naturels quels que soit leur taille
comme des noeuds et leur attribue un admin_level=15 (totalement
synthétique) pour classer les résultats. Il les considère plus petits que
les noms de batiments (house_name) auxquels il veut les attacher
pouyr attribuer une adresse et sinon il cherche un highway.
Ces éléments naturels sont donc classés n'importe comment.

Et je ne spécule pas du tout sur le fait qu'il crée bel et bien des noeuds
"place" artificiels, avec un id interne puisque c'est bien ce qu'il affiche
dans ses résultats. Et peu importe si cela ne correspond à rien et que
l'attribut synthétique admin_level ne correspond lui aussi à rien du tout.
La logique est totalement fausse qui conduit à les "rattacher" à d'autres
objets très éloignés et arbitraires qui n'incluient pourtant même pas du
tout ces noeuds synthétiques.

C'est une très grossière approximation de Nominatim: on ne peut pas réduire
ces objets à un simple noeud et Nominatim ne sait pas leur attacher
plutôt une bounding box pour avoir quelquechose de plus pertinent. Il se
base juste sur une mesure de distance entre deux noeuds (dont le noeud
artificiel et un autre noeud arbitraire d'un highway ou d'un vraie relation
boundary).

C'est très bancale. C'est un gros manque sur quelquechose qu'i n'a pas été
réellement développé mais laissé en vrac dans une classe fourre-tout
(pseudo-admin_level=15) en attendant un développement sérieux.
Tant que ces objets restent assimilable à un noeud et qu'ils sont
réellement inclus dans une relation admin_level ou assez proche à un
highway indexés pour les rendre "routables" (Nominatim n'indexe pas tous
les highways, seulement ceux ayant un nom ou un numéro de référence) il va
retourner n'importe quoi, c'est le hasard le plus complet en terme de
classification, il n'y a strictement rien qui soit alors réellement
pertinent.

Personellement je pense qu'une première amélioration de Nominatim serait
qu'il vire les noeuds "place" synthétiques pour les objets qui ne sont pas
des noeuds (objets linéraires et surfaces polygonales/multi-polygonales),
et qu'il les remplace au moins par des bounding box, afin de rendre les
calculs de pertinence bien meilleurs. Et il devrait le faire au moins pour
tous les objets actuellement classés en pseudo-admin_level=15. et sans
doute aussi (après tests pour éveluer les effets de bords dans la
détermination des adresses) pour les highways (quoique pour eux il vaudrait
sans doute mieux qu'il indexe les deux extrémités, à moins que ce soit un
chemin fermé ou que ce soit un "polyligne" formant des branches ou un
réseau dans une relation assimilable alors à une surface approximée par la
boundingbox)

Le sam. 17 oct. 2020 à 15:56, Sarah Hoffmann  a écrit :

> Bonjour,
>
> apropos la question pourquoi un lac s'attache a une rue et prends
> son adresse. C'est justement quelque chose qu'il faut revoir et
> probablement reviser. L'attachement aux rues marche bien pour les
> petits POIs comme boite aux lettres ou des supermarches. Ca marche
> meme bien pour un petit pont de village mais ce n'est pas une bonne
> idee pour les grandes lacs ou baies.
>
> Quand a toutes les autres speculations, j'ai vraiment pas envie de
> les discuter parce qu'ils sont exactement ca: speculations qui ont
> rien du tout a voir avec comment Nominatim fonctionne.
>
> Sarah
>
> On Sat, Oct 17, 2020 at 01:00:36PM +0200, Philippe Verdy wrote:
> > Tu ne réponds pas à la question ni au cas évoqué autour de
> > l'Île-Saint-Denis.
> >
> > En effet strictement rien n'associe ce polygone à la route en tant
> > "qu'adresse". C'est stupide comme association surtout pour ce type
> > d'élément. De plus c'est Nominatim qui en interne a généré un "place
> node"
> > (avec un ID interne) sur le polygone (il n'y a aucun node dans le
> polygone).
> >
> > En créant ce "place node", c'est là qu'il a cherché stupidement à lui
> > donner une adresse et à chercher une route proche. Et c'est là que
> > l'approximation commence à jouer et d'ailleurs tu n'expliques pas plus
> > pourquoi il trouve la relation associée à un lieu-dit ou hameau encore
> plus
> > éloigné dans la commune voisine, alors qu'il y a d'autres lieu-dits bien
> > plus proches et que cela n'a strictement rien à voir non plus avec la
> route
> > départementale trouvée dans les environs du noeud.
> >
> > Franchement c'est là que se joue l'approximation: le noeud interne
> "place"
> > ajouté ne représente pas correctement le plan d'eau, on pourrait toujours
> > tenter d'ajouter un noeud "label" dans la relation OSM je suis presque
> > certain que Nominatim n'en tiendra pas compte. Pas même si on sélectionne
> > ce noeud label sur la frontière intercommunale elle-même (ce qui ne sera
> > pas suffisant pour des relations à cheval sur plus d'une seule
> frontière).
> >
> > Et comment fait Nominatim pour même chercher une "adresse" (un highway)
> > sinon en procédant là aussi visiblement à une approximation ne tenant pas
> > compte de la 

Re: [Talk-GB] OSM UK's first tile layer

[Rob Nickerson]

Hi all,

To address this and some of the other questions:

>Can JOSM and iD display Mapbox .pbf vector tiles?
I don't think JOSM can which is a big shame as it would make it much easier
to host these sort of layers with minimal overhead.

>ensure any transformation from OSGB grid coordinates to WGS84 is accurate
enough
Yes indeed. Currently I used QGIS to transform the data for York however I
see that Mapnik can do the transform itself. For a complete GB dataset I
intend to download all files and bring them together to pass to Mapnik. It
probably then makes sense to have Mapnik do the transform. Any details on
what transformation I should be using would be much appreciated. Likewise
if you know a location that gets a big error if done wrong, that would help
me check.

>Thinner lines could work better
Yes, I think so too.

>consider increasing the max zoom a notch as well
Hopefully the new OSM UK board can investigate that as it will need a
beefier server so would push costs up.

>Are the numbers in wms tiles UPRNs?
My understanding is that they are not. That level of coordination would be
amazing but we're not there with Open Data yet!

P.S. If anyone is aware of the equivalent data for Northern Ireland, Isle
of Man or the Channel Islands, please let me know.

Best regards,
*Rob*


On Sat, 17 Oct 2020 at 08:16, Jez Nicholson  wrote:

> Nice one. I've been wanting to do this for ages.
>
> Re: file size. Can JOSM and iD display Mapbox .pbf vector tiles? These
> would be smaller.
>
> On Sat, 17 Oct 2020, 00:22 Rob Nickerson, 
> wrote:
>
>> Hi all,
>>
>> Just in time for the AGM, I have just published OSM UK's first tile
>> layer. No don't get too excited it is not a full map render. Instead I have
>> produced a very simple tiling of the Land Registry polygon data now that
>> this is under the OGL Open Data Licence. My view is that this is a good
>> layer to align our mapping too - i.e. when tracing from imagery we should
>> first align the imagery to the Land Registry polygon layer before tracing
>> from the imagery.
>>
>> The tile URL for JOSM is:
>> tms[13,17]:http://tiles.osmuk.org/LRpolygons/{zoom}/{x}/{y}.png
>>
>> And for now this is *York only* as an example.
>>
>> Feedback that I would appreciate:
>>
>>- Is this worthwhile?
>>- Do you agree that it makes sense for us to all try to align our
>>mapping to this (i.e. apply imagery offsets to align imagery to this 
>> before
>>tracing)?
>>- The style is very simple with just a 4 pixel red line. Is this
>>sufficient? What changes can be made?
>>- Any tips on how to keep the PNG file sizes as small as possible?
>>For now I am using the Mapnik rule "png8:c=2:t=1:m=o". Is there anything
>>that can yield smaller file sizes?
>>- What max zoom is worthwhile? Currently it goes to 17, is this
>>enough?
>>
>> Our plan would be to pre-render all the tiles and host them on our site.
>> The data doesn't change much so we would only re-render on request or once
>> a year. My estimate is that we'd need 35GB for tiles to zoom level 17, and
>> 133 GB to get everything to zoom 18. Our current server is on the small
>> side with just 512MB memory and a 100GB disk allowance. It is unsuitable
>> for on the fly rendering and we'd need more disk space to get the level 18
>> zoom. A beefier server is of course possible but any bump in specs comes
>> with an equal bump in costs so worth checking this is worthwhile before
>> proceeding.
>>
>> P.S. The Land Registry themselves host this data on a WMS service rather
>> than a TMS (tile) service. This makes it possible to zoom much further in.
>> If you want to have a look at that detail you can use their website or
>> (temporarily) use the following URL in JOSM. Please don't use this for
>> mapping as we don't have permission to use their WMS service
>>
>> wms:
>> http://inspire.landregistry.gov.uk/inspire/ows?SERVICE=WMS=image%2Fpng=inspire%3ACP.CadastralParcel=image%2Fpng=true=1.1.1=GetMap=_FORMAT=application%2Fvnd.ogc.gml=XML&_OLSALT=0.789927776902914={proj}={bbox}={width}={height}
>> 
>>
>> Best regards,
>> *Rob*
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] SPAM, Attribution manquante sur Inforoute

[osm . sanspourriel]

Philippe, merci de commencer à créer la page wiki, les scripts de
création de VM etc...

Jean-Yvon

Le 16/10/2020 à 23:29, Philippe Verdy - ver...@gmail.com a écrit :

Dommage qu'il n'utilisent pas un proxy cache pour les tuiles, c'est
directement les tuiles d'OSM.org.

C'est vraiment si compliqué d'installer un proxy cache (quitte à
restreindre la zone navigable et/ou le niveau de zoom nécessaire pour
les infos à afficher dessus, pour que cela ne prenne pas beaucoup de
ressources réseau pour les mises à jour du cache du proxy, ni beaucoup
d'espace de stockage)?



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

Bonjour,

apropos la question pourquoi un lac s'attache a une rue et prends
son adresse. C'est justement quelque chose qu'il faut revoir et
probablement reviser. L'attachement aux rues marche bien pour les
petits POIs comme boite aux lettres ou des supermarches. Ca marche
meme bien pour un petit pont de village mais ce n'est pas une bonne
idee pour les grandes lacs ou baies.

Quand a toutes les autres speculations, j'ai vraiment pas envie de
les discuter parce qu'ils sont exactement ca: speculations qui ont
rien du tout a voir avec comment Nominatim fonctionne. 

Sarah

On Sat, Oct 17, 2020 at 01:00:36PM +0200, Philippe Verdy wrote:
> Tu ne réponds pas à la question ni au cas évoqué autour de
> l'Île-Saint-Denis.
> 
> En effet strictement rien n'associe ce polygone à la route en tant
> "qu'adresse". C'est stupide comme association surtout pour ce type
> d'élément. De plus c'est Nominatim qui en interne a généré un "place node"
> (avec un ID interne) sur le polygone (il n'y a aucun node dans le polygone).
> 
> En créant ce "place node", c'est là qu'il a cherché stupidement à lui
> donner une adresse et à chercher une route proche. Et c'est là que
> l'approximation commence à jouer et d'ailleurs tu n'expliques pas plus
> pourquoi il trouve la relation associée à un lieu-dit ou hameau encore plus
> éloigné dans la commune voisine, alors qu'il y a d'autres lieu-dits bien
> plus proches et que cela n'a strictement rien à voir non plus avec la route
> départementale trouvée dans les environs du noeud.
> 
> Franchement c'est là que se joue l'approximation: le noeud interne "place"
> ajouté ne représente pas correctement le plan d'eau, on pourrait toujours
> tenter d'ajouter un noeud "label" dans la relation OSM je suis presque
> certain que Nominatim n'en tiendra pas compte. Pas même si on sélectionne
> ce noeud label sur la frontière intercommunale elle-même (ce qui ne sera
> pas suffisant pour des relations à cheval sur plus d'une seule frontière).
> 
> Et comment fait Nominatim pour même chercher une "adresse" (un highway)
> sinon en procédant là aussi visiblement à une approximation ne tenant pas
> compte de la géométrie réelle mais juste des bounding box (comme on le voit
> dans l'exemple trouvé aussi autour de l'Isle-Saint-Denis, où des objets
> situés dans une concavité de l'île mais dans la commune à l'ouest de l'île
> ne sont trouvés que dans la commune à l'est de l'ile car ils sont dans une
> concavité encore plus grande.
> 
> Ce sont bien les concavités frontalières qui causent problème ici: l'algo
> de recherche d'association de noeuds aux adresses "proches" est
> carrément faux dans ce cas, et encore plus quand ce noeud créé
> artificiellement ne peut pas luis seul représenter la surface d'un
> (multi-)polygone.
> 
> Le mode "debug" ici ne répond pas du tout à ce que fait Nominatim, il donne
> juste un aperçu sur la façon dont un objet isolé a été indexé (sur quels
> champs "utiles") mais pas du tout comment cet index sera ensuite utilisdé
> dans une recherche, notamment pour découper une chaine unique en éléments
> "pertinents", créer des listes d'objets indexés candidats,
> éliminer sauvagement des objets dans ces listes en ne retenant que les plus
> "probables" avant de calculer des intersections pour "accélérer" le calcul
> d'intersections de ces listes (note: il y a différentes façon de
> découper/simplifier la chaine de recherche, plus elle est longues et plus
> le nombre de possibilités croit exponentiellement, Nominatim doit faire des
> simplifications pour réduire le nombre de possibilités à croiser, et il
> simplifie aussi le traitement des géométries pendant le croisement des
> listes d'objets en tronquant ces listes avec des critères de "pertinence"
> non basés sur la géométrie réelle mais ici on  voit que c'est même pire
> puisqu'il se contente juste d'une géométrie réduite à un seul noeud
> artificiel, et au final, il peut se retrouver avec une liste totalement
> vide, ou sinon une liste n'ayant plus assez de candidats, ou un seul qui
> n'est plus du tout pertinent et qu'il ne vérifie finalement même pas à la
> fin pour voir si la géométrie correspond.
> 
> Quand Nominatim ne trouve pas d'objets ou n'en retrouve pas assez, il ne
> sait pas réduire lui-même ses critères de pertinence (pour ne pas filtrer
> aussi sauvement ses listes d'objets à croiser avant de faire l'assemblage
> et le croisement sur les éléments assemblés de la chaine de recherche). Il
> n'utilise pas du tout la géométrie réelle, pour lui tout objet indexé est
> réduit à un noeud unique, qui peut être arbitraire, et c'est même pire que
> s'il avait réduit la géométrie non pas à un seul noeud mais à une
> 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 

Re: [OSM-ja] 自然災害伝承碑データのインポート

[tomoya muramoto]

ありがとうございます。年を記載しました。
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] 自然災害伝承碑データのインポート

[OKADA Tsuneo]

岡田です。

muramotoさん、import作業ありがとうございます。

wikiページにつき、スケジュールの項の日付に年が書かれていませんので、
2020年であることを書いてあると、数年後に見てもわかりやすいかと思います。

よろしくお願いします。


2020年10月17日(土) 9:11 tomoya muramoto :

> インポート計画ページに英語説明を追記しました。
> 後ほどImport-mlにアナウンスする予定です。
>
>
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_GSI_Memorial_of_Natural_Hazard
>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>


-- 
岡田常雄(OKADA Tsuneo)
tsuneo.ok...@gmail.com
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] Nominatim et plan d'eau

[Philippe Verdy]

Et d'ailleurs ça se voit concernant son analyse de "pertinence": il retient
la départementale comme "pertinente" car il a déterminé la distance comme
étant nulle, ce qui est ici totalement faux; les distances calculées sont
fausses, même pour le noeud "place" ajouté artificiellement (il y a aussi
un autre noeud "place" artificiel pour la départementale).

C'est carrément stupide, les objets ne peuvent pas être valament
représentés par un seul noeud (comme décrit sur
https://nominatim.org/release-docs/develop/api/Output/#place_id-is-not-a-persistent-id),
il en faudrait au moins 2 pour calculer une pertinence non pas sur la seule
distance de point à point, mais en tenant compte des surfaces
d'intersection des rectangles et sinon en prenant la distance minimale
d'écart entre ces rectangles (20 cas possibles de placement relatif quand
il n'y a aucune intersection entre 2 rectangles dont 21 façons de calculer
cette distance minimale) comme un critère de valeur négative.

Et même avec cette modif, on va avoir des cas tordus dans les concavités
frontalières ou les méandres du linéaire des rues/routes pour rechercher
une adresse pertinente, et c'et là qu'il faut une notation seondaire pour
mieux trier les listes d'objets ou revoir les seuils de filtrage en amont

Cependant ce que tu suggères est que pour cet étang, il suffirait de nommer
la petite route qui la borde et vient du sud-ouest.

Mais tu n'explique pas du tout pourquoi ce n'est pas suffisant dans le cas
du Quai d'Asnières à côté de l'île-Saint-Denis, un cas qui nécessite de
tenir compte de la géométrie réelle et pas d'une simple approximation à un
seul noeud artificiel ni même à une bounding-box car on n'ira pas non plus
ajouter un nouveau nom qui existe déjà et n'a pas besoin d'être ajouté
artificiellement dans la base de données en tant que pseudo-nom (on a déjà
eu les "pseudo-noeuds" avec les membres de rôle "label" dans les relations,
des noeuds que Nominatim n'utilise plus du tout, ni non plus la plupart des
moteurs de rendus. Nominatim n'utilise pas non plus les noeuds
"admin_centre" alors qu'ils seraient encore utiles pour affiner la note de
pertinence au delà du seul noeud (ou de la seule bounding box) et éviter un
filtrage trop précoce des listes d'objets candidats avant le croisement de
ces listes (cela lui permettrait la plupart du temps de continuer à
travailler en une seule passe).







Le sam. 17 oct. 2020 à 13:00, Philippe Verdy  a écrit :

> Tu ne réponds pas à la question ni au cas évoqué autour de
> l'Île-Saint-Denis.
>
> En effet strictement rien n'associe ce polygone à la route en tant
> "qu'adresse". C'est stupide comme association surtout pour ce type
> d'élément. De plus c'est Nominatim qui en interne a généré un "place node"
> (avec un ID interne) sur le polygone (il n'y a aucun node dans le polygone).
>
> En créant ce "place node", c'est là qu'il a cherché stupidement à lui
> donner une adresse et à chercher une route proche. Et c'est là que
> l'approximation commence à jouer et d'ailleurs tu n'expliques pas plus
> pourquoi il trouve la relation associée à un lieu-dit ou hameau encore plus
> éloigné dans la commune voisine, alors qu'il y a d'autres lieu-dits bien
> plus proches et que cela n'a strictement rien à voir non plus avec la route
> départementale trouvée dans les environs du noeud.
>
> Franchement c'est là que se joue l'approximation: le noeud interne "place"
> ajouté ne représente pas correctement le plan d'eau, on pourrait toujours
> tenter d'ajouter un noeud "label" dans la relation OSM je suis presque
> certain que Nominatim n'en tiendra pas compte. Pas même si on sélectionne
> ce noeud label sur la frontière intercommunale elle-même (ce qui ne sera
> pas suffisant pour des relations à cheval sur plus d'une seule frontière).
>
> Et comment fait Nominatim pour même chercher une "adresse" (un highway)
> sinon en procédant là aussi visiblement à une approximation ne tenant pas
> compte de la géométrie réelle mais juste des bounding box (comme on le voit
> dans l'exemple trouvé aussi autour de l'Isle-Saint-Denis, où des objets
> situés dans une concavité de l'île mais dans la commune à l'ouest de l'île
> ne sont trouvés que dans la commune à l'est de l'ile car ils sont dans une
> concavité encore plus grande.
>
> Ce sont bien les concavités frontalières qui causent problème ici: l'algo
> de recherche d'association de noeuds aux adresses "proches" est
> carrément faux dans ce cas, et encore plus quand ce noeud créé
> artificiellement ne peut pas luis seul représenter la surface d'un
> (multi-)polygone.
>
> Le mode "debug" ici ne répond pas du tout à ce que fait Nominatim, il
> donne juste un aperçu sur la façon dont un objet isolé a été indexé (sur
> quels champs "utiles") mais pas du tout comment cet index sera ensuite
> utilisdé dans une recherche, notamment pour découper une chaine unique en
> éléments "pertinents", créer des listes d'objets indexés candidats,
> éliminer sauvagement des objets dans ces listes en ne 

Re: [OSM-talk-fr] Nominatim et plan d'eau

[Philippe Verdy]

Tu ne réponds pas à la question ni au cas évoqué autour de
l'Île-Saint-Denis.

En effet strictement rien n'associe ce polygone à la route en tant
"qu'adresse". C'est stupide comme association surtout pour ce type
d'élément. De plus c'est Nominatim qui en interne a généré un "place node"
(avec un ID interne) sur le polygone (il n'y a aucun node dans le polygone).

En créant ce "place node", c'est là qu'il a cherché stupidement à lui
donner une adresse et à chercher une route proche. Et c'est là que
l'approximation commence à jouer et d'ailleurs tu n'expliques pas plus
pourquoi il trouve la relation associée à un lieu-dit ou hameau encore plus
éloigné dans la commune voisine, alors qu'il y a d'autres lieu-dits bien
plus proches et que cela n'a strictement rien à voir non plus avec la route
départementale trouvée dans les environs du noeud.

Franchement c'est là que se joue l'approximation: le noeud interne "place"
ajouté ne représente pas correctement le plan d'eau, on pourrait toujours
tenter d'ajouter un noeud "label" dans la relation OSM je suis presque
certain que Nominatim n'en tiendra pas compte. Pas même si on sélectionne
ce noeud label sur la frontière intercommunale elle-même (ce qui ne sera
pas suffisant pour des relations à cheval sur plus d'une seule frontière).

Et comment fait Nominatim pour même chercher une "adresse" (un highway)
sinon en procédant là aussi visiblement à une approximation ne tenant pas
compte de la géométrie réelle mais juste des bounding box (comme on le voit
dans l'exemple trouvé aussi autour de l'Isle-Saint-Denis, où des objets
situés dans une concavité de l'île mais dans la commune à l'ouest de l'île
ne sont trouvés que dans la commune à l'est de l'ile car ils sont dans une
concavité encore plus grande.

Ce sont bien les concavités frontalières qui causent problème ici: l'algo
de recherche d'association de noeuds aux adresses "proches" est
carrément faux dans ce cas, et encore plus quand ce noeud créé
artificiellement ne peut pas luis seul représenter la surface d'un
(multi-)polygone.

Le mode "debug" ici ne répond pas du tout à ce que fait Nominatim, il donne
juste un aperçu sur la façon dont un objet isolé a été indexé (sur quels
champs "utiles") mais pas du tout comment cet index sera ensuite utilisdé
dans une recherche, notamment pour découper une chaine unique en éléments
"pertinents", créer des listes d'objets indexés candidats,
éliminer sauvagement des objets dans ces listes en ne retenant que les plus
"probables" avant de calculer des intersections pour "accélérer" le calcul
d'intersections de ces listes (note: il y a différentes façon de
découper/simplifier la chaine de recherche, plus elle est longues et plus
le nombre de possibilités croit exponentiellement, Nominatim doit faire des
simplifications pour réduire le nombre de possibilités à croiser, et il
simplifie aussi le traitement des géométries pendant le croisement des
listes d'objets en tronquant ces listes avec des critères de "pertinence"
non basés sur la géométrie réelle mais ici on  voit que c'est même pire
puisqu'il se contente juste d'une géométrie réduite à un seul noeud
artificiel, et au final, il peut se retrouver avec une liste totalement
vide, ou sinon une liste n'ayant plus assez de candidats, ou un seul qui
n'est plus du tout pertinent et qu'il ne vérifie finalement même pas à la
fin pour voir si la géométrie correspond.

Quand Nominatim ne trouve pas d'objets ou n'en retrouve pas assez, il ne
sait pas réduire lui-même ses critères de pertinence (pour ne pas filtrer
aussi sauvement ses listes d'objets à croiser avant de faire l'assemblage
et le croisement sur les éléments assemblés de la chaine de recherche). Il
n'utilise pas du tout la géométrie réelle, pour lui tout objet indexé est
réduit à un noeud unique, qui peut être arbitraire, et c'est même pire que
s'il avait réduit la géométrie non pas à un seul noeud mais à une
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 

Re: [Talk-GB] OSM UK's first tile layer

[ndrw]

Hi Rob,

Good stuff, it's definitely worthwhile. Thinner lines could work better 
(for me 1px would be perfect), especially that the max zoom stops at 17. 
You could perhaps consider increasing the max zoom a notch as well.


Are the numbers in wms tiles UPRNs? If so, you could consider displaying 
them as well.


Best regards,

ndrw6

On 17/10/2020 00:20, Rob Nickerson wrote:

Hi all,

Just in time for the AGM, I have just published OSM UK's first tile 
layer. No don't get too excited it is not a full map render. Instead I 
have produced a very simple tiling of the Land Registry polygon data 
now that this is under the OGL Open Data Licence. My view is that this 
is a good layer to align our mapping too - i.e. when tracing from 
imagery we should first align the imagery to the Land Registry polygon 
layer before tracing from the imagery.


The tile URL for JOSM is:
tms[13,17]:http://tiles.osmuk.org/LRpolygons/{zoom}/{x}/{y}.png

And for now this is _York only_ as an example.

Feedback that I would appreciate:

  * Is this worthwhile?
  * Do you agree that it makes sense for us to all try to align our
mapping to this (i.e. apply imagery offsets to align imagery to
this before tracing)?
  * The style is very simple with just a 4 pixel red line. Is this
sufficient? What changes can be made?
  * Any tips on how to keep the PNG file sizes as small as possible?
For now I am using the Mapnik rule "png8:c=2:t=1:m=o". Is there
anything that can yield smaller file sizes?
  * What max zoom is worthwhile? Currently it goes to 17, is this enough?

Our plan would be to pre-render all the tiles and host them on our 
site. The data doesn't change much so we would only re-render on 
request or once a year. My estimate is that we'd need 35GB for tiles 
to zoom level 17, and 133 GB to get everything to zoom 18. Our current 
server is on the small side with just 512MB memory and a 100GB disk 
allowance. It is unsuitable for on the fly rendering and we'd need 
more disk space to get the level 18 zoom. A beefier server is of 
course possible but any bump in specs comes with an equal bump in 
costs so worth checking this is worthwhile before proceeding.


P.S. The Land Registry themselves host this data on a WMS service 
rather than a TMS (tile) service. This makes it possible to zoom much 
further in. If you want to have a look at that detail you can use 
their website or (temporarily) use the following URL in JOSM. Please 
don't use this for mapping as we don't have permission to use their 
WMS service


wms:http://inspire.landregistry.gov.uk/inspire/ows?SERVICE=WMS=image%2Fpng=inspire%3ACP.CadastralParcel=image%2Fpng=true=1.1.1=GetMap=_FORMAT=application%2Fvnd.ogc.gml=XML&_OLSALT=0.789927776902914={proj}={bbox}={width}={height}

Best regards,
*Rob*

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


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

Re: [Talk-GB] OSM UK's first tile layer

[Robert Whittaker (OSM lists)]

On Sat, 17 Oct 2020 at 00:22, Rob Nickerson  wrote:
> Just in time for the AGM, I have just published OSM UK's first tile layer. No 
> don't get too excited it is not a full map render. Instead I have produced a 
> very simple tiling of the Land Registry polygon data now that this is under 
> the OGL Open Data Licence. My view is that this is a good layer to align our 
> mapping too - i.e. when tracing from imagery we should first align the 
> imagery to the Land Registry polygon layer before tracing from the imagery.
>
> The tile URL for JOSM is:
> tms[13,17]:http://tiles.osmuk.org/LRpolygons/{zoom}/{x}/{y}.png

Excellent. Ever since the new Bing imagery landed, I've been after a
good source to align things to. I've been having to rely on my own GPS
traces and/or existing mapping so far.

By the way, when there was some previous discussion on this list about
using OS data for imagery alignment, an issue was raised about needing
to ensure any transformation from OSGB grid coordinates to WGS84 is
accurate enough:
https://lists.openstreetmap.org/pipermail/talk-gb/2020-August/025077.html
. Popular transforms may be out by a few meters (which would be
noticeable in our detailed mapping.) Are you doing such a
transformation, and are you sure what you're doing is sufficiently
accurate?

Robert.

-- 
Robert Whittaker

-- 
Robert Whittaker

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

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-fr] BANO : documentation

[Jacques Lavignotte]

Le 17/10/2020 à 09:39, Vincent de Château-Thierry a écrit :

Bonjour,


Bonjour VincentDCT

Merci d'avoir ré-ouvert le dossier.

Merci à ceux que le 
sujet intéresse de venir participer sur ce ticket, aussi bien en testant 
les parties documentées, qu'en aidant à la rédaction et à la mise en forme.



J'en suis.


vincent


J.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

[OSM-talk-fr] BANO : documentation

[Vincent de Château-Thierry]

Bonjour,

J'amorce dans ce ticket https://github.com/osm-fr/bano/issues/204 la 
rédaction d'une doc d'installation et d'utilisation de BANO. L'idée in 
fine est d'obtenir un document permettant à celles-ceux qui veulent 
d'installer et faire tourner leur propre instance. Merci à ceux que le 
sujet intéresse de venir participer sur ce ticket, aussi bien en testant 
les parties documentées, qu'en aidant à la rédaction et à la mise en forme.


vincent


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

Re: [Talk-GB] OSM UK's first tile layer

[Jez Nicholson]

Nice one. I've been wanting to do this for ages.

Re: file size. Can JOSM and iD display Mapbox .pbf vector tiles? These
would be smaller.

On Sat, 17 Oct 2020, 00:22 Rob Nickerson,  wrote:

> Hi all,
>
> Just in time for the AGM, I have just published OSM UK's first tile layer.
> No don't get too excited it is not a full map render. Instead I have
> produced a very simple tiling of the Land Registry polygon data now that
> this is under the OGL Open Data Licence. My view is that this is a good
> layer to align our mapping too - i.e. when tracing from imagery we should
> first align the imagery to the Land Registry polygon layer before tracing
> from the imagery.
>
> The tile URL for JOSM is:
> tms[13,17]:http://tiles.osmuk.org/LRpolygons/{zoom}/{x}/{y}.png
>
> And for now this is *York only* as an example.
>
> Feedback that I would appreciate:
>
>- Is this worthwhile?
>- Do you agree that it makes sense for us to all try to align our
>mapping to this (i.e. apply imagery offsets to align imagery to this before
>tracing)?
>- The style is very simple with just a 4 pixel red line. Is this
>sufficient? What changes can be made?
>- Any tips on how to keep the PNG file sizes as small as possible? For
>now I am using the Mapnik rule "png8:c=2:t=1:m=o". Is there anything that
>can yield smaller file sizes?
>- What max zoom is worthwhile? Currently it goes to 17, is this enough?
>
> Our plan would be to pre-render all the tiles and host them on our site.
> The data doesn't change much so we would only re-render on request or once
> a year. My estimate is that we'd need 35GB for tiles to zoom level 17, and
> 133 GB to get everything to zoom 18. Our current server is on the small
> side with just 512MB memory and a 100GB disk allowance. It is unsuitable
> for on the fly rendering and we'd need more disk space to get the level 18
> zoom. A beefier server is of course possible but any bump in specs comes
> with an equal bump in costs so worth checking this is worthwhile before
> proceeding.
>
> P.S. The Land Registry themselves host this data on a WMS service rather
> than a TMS (tile) service. This makes it possible to zoom much further in.
> If you want to have a look at that detail you can use their website or
> (temporarily) use the following URL in JOSM. Please don't use this for
> mapping as we don't have permission to use their WMS service
>
> wms:
> http://inspire.landregistry.gov.uk/inspire/ows?SERVICE=WMS=image%2Fpng=inspire%3ACP.CadastralParcel=image%2Fpng=true=1.1.1=GetMap=_FORMAT=application%2Fvnd.ogc.gml=XML&_OLSALT=0.789927776902914={proj}={bbox}={width}={height}
> 
>
> Best regards,
> *Rob*
> ___
> 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