Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source

[Philippe Verdy]

J'ai bien compris la role de 'layer" mais ça ne fonctionne pas dans la
formule publiée où ce n'est qu'un facteur d'échelle: layer=2 multiplie les
id retournés par 2 mais un id=2 créé par une telle valeur de layer entre en
collision avec l'id=1 pour un autre noeud situé ailleurs sur la carte à la
précision donnée.
Ce n'est donc PAS une multiplication mais une addition (d'une constante)
qu'il faut faire pour séparer les id's de noeuds sur des layers différents.
Chaque layer numérote ses noeuds sur une grille N*N correspondant aux
latitudes/longitudes arrondies au facteur de zoom près, il faut donc bien
*ajouter* (layer*N*N). Ici N=2^zoom et c'est le zoom ici qui tient lieu de
niveau de précision (avec zoom=0, la grille N*N ne fait que 1*1 et se
réduit à 1 point pour toute la planète positionné à la longitude 0 et la
latitude 0, donc sur sur l'équateur et le Méridien de Greenwich, légèrement
décalé dans WGS84, ce point étant dans le Golfe de Guinée à l'ouest de
l'Afrique centrale). Avec le zoom=1 on a 4 points sur la planisphère WGS84
mais 2 des points sont au pole sud, le troisième est l'antipode du premier
point aussi sur l'équateur. Les points de la grille délimitent à chaque
fois 4 carreaux divisant le premier en parties égales en surface et en
côtés sur la planisphère.

Le facteur d'échelle (2^zoom) est ce qui est classiquement utilisé sur OSM,
chaque zoom supplémentaire divisant l'angle total de 360° (en longitude
comme en latitude) par 2.

La niveau de zoom 8 correspond à une précision légèrement supérieure à 1
degré (on peut aussi le traduire en distance grâce au rayon moyen de la
Terre pour une distance mesurée sur un géoïde parfaitement sphérique, ce
que la Terre n'est évidemment pas à sa surface étant donné sa forme
ovoïdale aplatie aux pôles et le relief, c'est pour ça qu'on parle juste de
rayon moyen et sur OSM on retient une moyenne mesurée sur le plan de
l'équateur au niveau moyen de la mer, ou bien la longueur totale de
l'équateur, soit environ 10 000 km pour ses 90° de longitude sur un quart
de l'équateur)

De fait pas besoin du paramètre "précision", "zoom" en tient lieu.

La combinaison de latitude et longitude en un seul entier peut se faire de
deux façon:
* avec la fonction ST_QUAD (par entrelacement alterné des bits de longitude
et latitude), qui existe déjà dans la base PostGIS que tu utilises et qui
sert déjà pour indexer les recherches par coordonnées proches au sein d'un
même carreau et permet de définir un intervalle carré englobant le point
cherché;
* ou en multipliant une des coordonnées par la borne supérieure (non
incluse) de l'autre coordonnée, donc (2^zoom), et non pas une
multiplication par un "nombre premier supérieur à 10^précision"; le
nombre premier n'apporte rien, plus facile à calculer mais pas pratique
pour indexer les coordonnées 2D car cela divise la carte en bandes
ultrafines avec de nombreux points faisant tout le tour de la Terre avant
le point proche de la bande suivante ou précédente.

L'anomalie que j'ai signalée concerne justement le facteur "layer"
(utiliser un nombre premier > 10^précision dans la formule initiale marche,
mais la restriction aux premiers ne sert à rien et le nombre=10^precision
marche aussi donc pas besoin de ">").


Le mar. 26 mai 2020 à 19:30, François Lacombe  a
écrit :

> Philippe, je crois que tu ne comprends pas.
>
> Le mar. 26 mai 2020 à 17:24, Philippe Verdy  a écrit :
>
>> Justement j'ai proposé un patch, pas juste exposé les problèmes. C'est
>> nécessaire pour éviter que ce code maintenant publié soit utilisé tel quel
>> sans correction au risque d'importer des géométries farfelues, car un tel
>> script peut servir à faire des imports en masse sans trop regarder...
>>
>
> Proposer un patch de cette façon en l'assortissant de phrases buttoir
> n'apporte rien et surtout décourage d'autres de publier leur contribution,
> si c'est pour avoir à faire à ce genre de discours.
> Personne n'a parlé d'import dans OSM. Les cas d'usage proposés étaient
> d'utiliser certains logiciels, en particulier osrm, avec des données qui ne
> viennent pas d'OSM.
>
> Mon utilisation est certainement trop limitée pour avoir vu le problème
> des antipodes.
> Que le code soit perfectible, certes. On ne va quand même pas attendre
> qu'il soit parfait pour le publier?
> Tu ne semble pas avoir compris pourquoi les layers avaient été introduits
> ici. Quand on combine plusieurs jeux de données, des nœuds peuvent se
> trouver au même endroit sans devoir être fusionnés.
>
> +1 avec Adrien et Jérôme, j'ai tout simplement pas envie de regarder la
> suite.
>
> François
> ___
> 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] DCbrain rend publique une partie de son code en open source

[François Lacombe]

Philippe, je crois que tu ne comprends pas.

Le mar. 26 mai 2020 à 17:24, Philippe Verdy  a écrit :

> Justement j'ai proposé un patch, pas juste exposé les problèmes. C'est
> nécessaire pour éviter que ce code maintenant publié soit utilisé tel quel
> sans correction au risque d'importer des géométries farfelues, car un tel
> script peut servir à faire des imports en masse sans trop regarder...
>

Proposer un patch de cette façon en l'assortissant de phrases buttoir
n'apporte rien et surtout décourage d'autres de publier leur contribution,
si c'est pour avoir à faire à ce genre de discours.
Personne n'a parlé d'import dans OSM. Les cas d'usage proposés étaient
d'utiliser certains logiciels, en particulier osrm, avec des données qui ne
viennent pas d'OSM.

Mon utilisation est certainement trop limitée pour avoir vu le problème des
antipodes.
Que le code soit perfectible, certes. On ne va quand même pas attendre
qu'il soit parfait pour le publier?
Tu ne semble pas avoir compris pourquoi les layers avaient été introduits
ici. Quand on combine plusieurs jeux de données, des nœuds peuvent se
trouver au même endroit sans devoir être fusionnés.

+1 avec Adrien et Jérôme, j'ai tout simplement pas envie de regarder la
suite.

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

Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source

[Philippe Verdy]

Justement j'ai proposé un patch, pas juste exposé les problèmes. C'est
nécessaire pour éviter que ce code maintenant publié soit utilisé tel quel
sans correction au risque d'importer des géométries farfelues, car un tel
script peut servir à faire des imports en masse sans trop regarder...
J'ai donc proposé une formule corrigée en expliquant, libre à l'auteur d'en
tenir compte, mais au moins ma remarque est publique et d'autres peuvent la
voir dans la liste des correctifs proposés.

Je pense que l'auteur corrigera (il n'est pas obligé de prendre mon patch
tel quel, il y a bien d'autres moyens de calculer un node-id sans prendre
en compte dans l'id les coordonnées réelles, ce qui donne des clés entières
assez élevées, dépassant la capacité d'un entier, même en 64-bits, si on
veut la précision demandée sur OSM)

La précision sur OSM peut monter actuellement au dixième de seconde d'arc
soit 5 décimales environs, mais OSM peut monter à 7 décimales pour une
précision centimétrique (qui commence à être utilisée par endroit dans les
zones très denses), bien que les outils GPS n'ont cette précision que pour
les coordonnées satellitaires, mais pas du tout les coordonnées fixes au
sol à cause des déplacements techtoniques non uniformes et autres
déformations géologiques ou érosives du terrain: les différents pays ont
des modèles de coordonnées fixes qui leur sont propres, région par région,
et qui évoluent indépendamment de la précision satellitaire coordonnée au
plan mondial, donc on a de gros doutes sur les précisions centimétriques
valables seulement à certaines dates et qui changent d'année en année, et
OSM ne trace pas non plus les dates des noeuds en fonction de leur source,
mais uniquement en fonction de la date de modif/d'ajout/d'intégration dans
OSM)

Au mieux OSM ne peut donc avoir qu'une précision métrique au plan mondial,
et sinon, sur des zone distances ne dépassant pas quelques kilomètres, une
précision *relative* centimétrique mais non coordonnée de façon aboslue. Et
on n'a pas encore de modèle mondial permettant de cadres précisément tous
les référentiels géographiques locaux ou nationaux et leurs évolutions,
aucun indication du référentiel utilisé dans les noeuds où tous les modèles
des différentes sources et dates sont mélangés. Rien que le RGF légal
français évolue indépendamment du WGS84, et entre les deux les écarts
évoluent en permanence: une partie des données peuvent être précises au
centimètre près, mais on n'a aucun moyen de les délimiter si elles sont
mélangées aux autres toutes aussi précises mais selon un autre référentiel,
ou d'autres moins précises. Le travail de "fusion" consiste à chercher à
plus ou moins les accorder à un instant donné sans garantie que ce sera
stable pour l'avenir. Même les orthophotos évoluent avec l'évolution des
MNT dont la prise en compte n'est pas synchronisée.

OSM ne peut pas y faire grand chose, c'est aux sources de  trouver les
moyens de coordonner leurs modèles et publier les corrections apportées.
avec OSM on fait de notre mieux au milieu de cette variété, seulement pour
que la fusion obtenue soit à peut près conforme à une réalité constatée
localement à un instant donné, mais on ne peut pas stabiliser ces données
mieux qu'avec une précision globale métrique et décimétrique dans les zones
les plus développées suffisamment riches en sources de données qu'on peut
comparer entre elles.


Le mar. 26 mai 2020 à 13:33, PanierAvide  a écrit :

> Ça fait toujours plaisir de bon matin la bienveillance de la communauté du
> libre ;-) Les bonnes pratiques : d'abord le positif, ensuite les critiques
> constructives, enfin rester dans la bienveillance et la volonté de proposer
> un logiciel de meilleure qualité pour tous <3
>
> Cordialement,
>
> Adrien P.
>
> Le 26/05/2020 à 13:17, François Lacombe a écrit :
>
> Bonjour Philippe,
>
> Le mar. 26 mai 2020 à 06:52, Philippe Verdy  a écrit :
>
>> Ce code source n'apporte strictement rien.
>>
>
> Merci à toi.
>
> Bonne journée
>
> François
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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] DCbrain rend publique une partie de son code en open source

[Jérôme Seigneuret]

Le mar. 26 mai 2020 à 06:52, Philippe Verdy  a écrit :

> Ce code source n'apporte strictement rien.
>
Ça a le mérite d'être clair!

>
> Pas même sa description qui est fonctionnellement aberrante concernant la
> formule des "node id", un pseudo-hashcode qui n'en est même pas un, qui
> réclame un nombre premier pour encoder le couple de coordonnées alors que
> cela n'a rien à voir et qu'il n'est pas nécessaire du tout que ce soit
> premier, on peut directement utiliser "180*10^precision" à la place de
> "prime" en voyant que les latitudes sont données en degrés entre -90.0
> et +90.0, ou bien  "360*10^precision" si les latitudes ne sont pas
> normalisées à cet intervalle et reboucle chaque méridien avec son
> antiméridien (au quel cas un module 360 suffit sur chacune des deux
> coordonnées à les normaliser "à moitié", sans unifier un point et son
> antipode situé à la même longitude mais à la latitude+180°)
>
>round(mod(lat, 360), precision) + round(mod(lon, 360) , precision) *
> 360*10^precision
>
Le code source est libéré je pense que tu peux proposer quelque chose en ce
sens qui permettrait à la communauté quelque choses de constructif

>
> Les arrondis sont mal exprimés aussi dans la formule originale qui va donc
> confondre une partie de la précision de la longitude en recouvrant des
> points ailleurs à une autre longitude.
>
> [Pour une unification complète des points antipodiques, il faut un test
> d'intervalle pour la latitude modulo 360, pour la ramener à un intervalle
> large de 180°, en ajoutant ou pas 180° à la longitude, selon la parité de
> l'intervalle de latitude, et en remplaçant ou pas la latitude par son
> complémentaire à 180° selon la même parité]. Et je pense même que c'est
> inutile à moins que la base QGis stocke des coordonnées non normalisées
> (avec des latitudes hors de -90.0 à +90.0, même s'il est probable qu'elle
> puisse avoir en revanche des longitudes hors de l'intervalle -180.0 à +180°
> pour la cartographie le long de la ligne de changement de date (aux îles
> Kiribati, aux île Kouryles et à travers la pointe du Kamtchatka en Sibérie
> extrême-orientale, et sinon sur le continent antarctique dans le secteur
> revendiqué par l'Australie).
>
> Et concernant le paramètres "layer" qui multiplie le tout, c'est encore
> plus stupide, sa seule valeur valide est 1, toute autre valeur n'apporte
> rien d'autre qu'un changement d'échelle des ids, sauf la valeur 0 qui rend
> tous les ids générés nuls.
>
Pareillement. Peut-être que ça a une utilité justement pour le projet
originale pour filtrer un niveau d'échelle un peu comme le fait INTERLIS

>
> J'espère qu'une telle formule (totalement fausse) n'a jamais réellement
> été utilisée pour importer des géométries dans OSM!
>
Peut-être que SeFaireConnaitre ... Non je sors

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

Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source

[PanierAvide]

Ça fait toujours plaisir de bon matin la bienveillance de la communauté 
du libre ;-) Les bonnes pratiques : d'abord le positif, ensuite les 
critiques constructives, enfin rester dans la bienveillance et la 
volonté de proposer un logiciel de meilleure qualité pour tous <3


Cordialement,

Adrien P.

Le 26/05/2020 à 13:17, François Lacombe a écrit :

Bonjour Philippe,

Le mar. 26 mai 2020 à 06:52, Philippe Verdy > a écrit :


Ce code source n'apporte strictement rien.


Merci à toi.

Bonne journée

François

___
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] DCbrain rend publique une partie de son code en open source

[François Lacombe]

Bonjour Philippe,

Le mar. 26 mai 2020 à 06:52, Philippe Verdy  a écrit :

> Ce code source n'apporte strictement rien.
>

Merci à toi.

Bonne journée

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

Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source

[Philippe Verdy]

Ce code source n'apporte strictement rien.

Pas même sa description qui est fonctionnellement aberrante concernant la
formule des "node id", un pseudo-hashcode qui n'en est même pas un, qui
réclame un nombre premier pour encoder le couple de coordonnées alors que
cela n'a rien à voir et qu'il n'est pas nécessaire du tout que ce soit
premier, on peut directement utiliser "180*10^precision" à la place de
"prime" en voyant que les latitudes sont données en degrés entre -90.0
et +90.0, ou bien  "360*10^precision" si les latitudes ne sont pas
normalisées à cet intervalle et reboucle chaque méridien avec son
antiméridien (au quel cas un module 360 suffit sur chacune des deux
coordonnées à les normaliser "à moitié", sans unifier un point et son
antipode situé à la même longitude mais à la latitude+180°)

   round(mod(lat, 360), precision) + round(mod(lon, 360) , precision) *
360*10^precision

Les arrondis sont mal exprimés aussi dans la formule originale qui va donc
confondre une partie de la précision de la longitude en recouvrant des
points ailleurs à une autre longitude.

[Pour une unification complète des points antipodiques, il faut un test
d'intervalle pour la latitude modulo 360, pour la ramener à un intervalle
large de 180°, en ajoutant ou pas 180° à la longitude, selon la parité de
l'intervalle de latitude, et en remplaçant ou pas la latitude par son
complémentaire à 180° selon la même parité]. Et je pense même que c'est
inutile à moins que la base QGis stocke des coordonnées non normalisées
(avec des latitudes hors de -90.0 à +90.0, même s'il est probable qu'elle
puisse avoir en revanche des longitudes hors de l'intervalle -180.0 à +180°
pour la cartographie le long de la ligne de changement de date (aux îles
Kiribati, aux île Kouryles et à travers la pointe du Kamtchatka en Sibérie
extrême-orientale, et sinon sur le continent antarctique dans le secteur
revendiqué par l'Australie).

Et concernant le paramètres "layer" qui multiplie le tout, c'est encore
plus stupide, sa seule valeur valide est 1, toute autre valeur n'apporte
rien d'autre qu'un changement d'échelle des ids, sauf la valeur 0 qui rend
tous les ids générés nuls.

J'espère qu'une telle formule (totalement fausse) n'a jamais réellement été
utilisée pour importer des géométries dans OSM!



> Le mer. 13 mai 2020 à 16:25,  a écrit :
>>
>>> DCbrain rend public un convertisseur de données, sur son compte Github.
>>> Il s'agit d'un convertisseur de données géographiques postgresql en format
>>> openstreetmap
>>> Apparemment c est en rapport avec OSRM
>>> Source:
>>> https://www.programmez.com/actualites/dcbrain-rend-publique-une-partie-de-son-code-en-open-source-30553
>>
>>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source

[Philippe Verdy]

Est-ce que ce n'est pas fonctionnellement équivalent au greffon pour JOSM
de chargement de données depuis une base QGis (donc sans la génération de
fichier XML .osm, que JOSM fait lui-même, juste la partie requête SQL)?

Le mer. 13 mai 2020 à 17:35, François Lacombe  a
écrit :

> Salut,
>
> Merci pour le relais.
> J'ai eu l'occasion de tremper dans cette sombre affaire.
>
> Le convertisseur est utilisé pour alimenter OSRM, mais c'est surtout le
> réciproque de osm2pgsql.
> Il produit un fichier xml osm à partir d'une base postgis.
>
> Cela ayant pour avantage de bénéficier de la force de postgis et de
> données tierces pour utiliser des logiciels qui n'acceptent que du xml en
> entrée.
> La valeur ajoutée résident dans le code SQL de création de la topologie
> avec les bonnes connections plus que dans l'écriture du XML qui devrait
> être revue prochainement.
>
> A dispo pour plus d'explications
>
> François
>
> Le mer. 13 mai 2020 à 16:25,  a écrit :
>
>> DCbrain rend public un convertisseur de données, sur son compte Github.
>> Il s'agit d'un convertisseur de données géographiques postgresql en format
>> openstreetmap
>> Apparemment c est en rapport avec OSRM
>>
>> Source:
>> https://www.programmez.com/actualites/dcbrain-rend-publique-une-partie-de-son-code-en-open-source-30553
>>
>> Julien
>>
>> ___
>> 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] DCbrain rend publique une partie de son code en open source

[François Lacombe]

Salut,

Merci pour le relais.
J'ai eu l'occasion de tremper dans cette sombre affaire.

Le convertisseur est utilisé pour alimenter OSRM, mais c'est surtout le
réciproque de osm2pgsql.
Il produit un fichier xml osm à partir d'une base postgis.

Cela ayant pour avantage de bénéficier de la force de postgis et de données
tierces pour utiliser des logiciels qui n'acceptent que du xml en entrée.
La valeur ajoutée résident dans le code SQL de création de la topologie
avec les bonnes connections plus que dans l'écriture du XML qui devrait
être revue prochainement.

A dispo pour plus d'explications

François

Le mer. 13 mai 2020 à 16:25,  a écrit :

> DCbrain rend public un convertisseur de données, sur son compte Github. Il
> s'agit d'un convertisseur de données géographiques postgresql en format
> openstreetmap
> Apparemment c est en rapport avec OSRM
>
> Source:
> https://www.programmez.com/actualites/dcbrain-rend-publique-une-partie-de-son-code-en-open-source-30553
>
> Julien
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] DCbrain rend publique une partie de son code en open source

[thevenon . julien]

DCbrain rend public un convertisseur de données, sur son compte Github. Il 
s'agit d'un convertisseur de données géographiques postgresql en format 
openstreetmap
Apparemment c est en rapport avec OSRM

Source: 
https://www.programmez.com/actualites/dcbrain-rend-publique-une-partie-de-son-code-en-open-source-30553

Julien

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