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
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
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
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
Ç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
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
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
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
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
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:
10 matches
Mail list logo
