Re: [OSM-talk-fr] Nom des cours d’eau dans le cadastre

[David Marchal]

Voici le plan en question : 
https://www.dropbox.com/s/3dnmurzhj3x2bqp/Plan.jpg?dl=0 ; si un connaisseur 
arrive à savoir d’où sort le nom du ruisseau…

Cordialement.

Le 3 févr. 2017 à 09:44, Jérôme Seigneuret 
> a écrit :

Bonjour,
il n'y a rien d'incohérent avec une extraction "dite du cadastre" car il existe 
des outils pour les géomètres avec bases de données déjà enrichies pour 
préparer des plans.
Sinon cela peut être extrait du Géoportail avec la surcouche parcelles 
cadastrales et une autre source de données en fond de plan comme la carte IGN 
en niveau de gris.

exemple

Sinon le géomètre à juste enrichi son fichier DWG...

Donc difficile de dire comment le plan a été réellement créé. Un lien pour voir 
le plan serait mieux pour émettre des hypothèses. Le mieux serait de savoir 
comment le géomètre a créé son plan (outils, données)

Pour moi les noms sont très rarement inscrit sur le plan cadastral.  En plus de 
ça, le nom n'est pas forcément à coté de la parcelle cadastrale concernée par 
par l'emprise géographique du plan en question (surtout si les données 
d'affichage sont au format raster ou rasterisé pour faire le fond de plan.

Jérôme
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Un peu de lecture

[NOUCHER Matthieu]

Bonjour,

Juste un petit mot pour vous signaler un article dans la revue en libre-accès 
M@ppemonde qui s'intéresse à la ligne de front du Donbass (Ukraine, Russie) et 
qui montre bien comment OSM propose une représentation alternative de cette 
zone de conflit (souvent invisible sur les cartes institutionnelles) : 
http://mappemonde.mgm.fr/119lieu1/

Bonne fin de week-end.

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

[OSM-talk-fr] Rencontre mensuelle OSM-Lyon 14/02/2017 18h30 - Invitation

[gnrc]

Bonjour à tous, 

Les mappeurs OSM de Lyon se rencontrent régulièrement le 2ème mardi de chaque 
mois, et chacun peut s'inviter et participer à ces rencontres. La prochaine 
aura lieu : 

le MARDI 14 FEVRIER à partir de 18h30 
à l'espace "Infolab TUBA, 1 Place Charles Béraudier, 69003 LYON" (esplanade 
gare Part-dieu). 

Accès : M° "Gare Part-Dieu"; Tram T1; Bus C1, C2, C6, C7, C13, C25, 25, 37, 38, 
70 ; Vélo'V "Gare Part-Dieu Ouest" 

Le CR de la rencontre précédente se trouve sur la page du Wiki-OSM au lien : 
https://wiki.openstreetmap.org/wiki/Lyon/Reunion_10_janvier_2017 

Si vous souhaitez mettre un sujet particulier à l'ordre du jour de la rencontre 
à venir, vous pouvez commenter la page préparatoire au lien : 
https://wiki.openstreetmap.org/wiki/Lyon/Reunion_14_fevrier_2017 

Venez nombreux ! 
Amicalement 

gnrc69 - Chaque goutte fait l’océan ! 


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

Re: [OSM-talk-fr] Coup de turbo sur le rendu BANO...

[Philippe Verdy]

Le compactage des index a un effet limité: si cela varie autant c'est que
tu n'as pas joué sur les paramètres de taux de remplissage des pages de
B-tree et que tu l'as laissé à sa valeur minimale de 50% (qui a l'avantage
d'accélérer les mises à jour au prix d'une augmentation de l'espace total
utilisé de +50% en moyenne). Passer le taux de remplissage minimal des
pages à 75-80% a un impact faible sur les mises à jour (typiquement une
mise à jour écrira un peu plus souvent 3 ou 4 pages de plus en cas de
scission/fusion de pages mais pas si souvent que ça: si le plus gros des
usages des index est en lecture pour faire un rendu des cartes, tu as
intérêt à monter ce taux de remplissage.

A 80% de taux de remplissage sans aucune maintenance de compactage la
taille des index ne sera augmentée en moyenne que de 10%, mais en lecture
tu augmenteras énormément l'efficacité du cache de pages en mémoire. Si 80%
te fais peur, essaye déjà à 75% (qui réduit déjà d'environ 2 pages mises à
jour en moins par rapport au taux de 80%, quand il y a fusion ou scission
de page, et diminue aussi la fréquence des fusions/scission de page
d'environ 30% lors des mises à jour d'index). Tu n'auras plus ensuite à
t'occuper de réindexer (ce qui pénalise en bloquant la base souvent trop
longtemps).

En général dans les bases de données j'ai toujours utilisé le taux de 75%
(mais sur des bases relationnelles d'entreprise sur lesquelles on fait de
nombreuses analyses statistiques et des recherches très dispersées de
clients, fournisseurs, factures, etc... on utilise typiquement le 80% par
défaut, et on ajuste ensuite en fonction de l'audit. Certains moteurs de
bases de données disposent d'outil d'audit automatiques qui peuvent
autoajuster ces taux en surveillant les I/O et regardant les plans
d'exécution et succès/échecs de prédiction de leur optimiseur de requêtes,
ou encore les temps de réponse attendus par les clients selon que ce sont
des requêtes interactives venant de nombreux clients ou des requêtes
d'analyse d'origine plus locale mais en masse et venant d'un moteur
statistique (ces moteurs pour monter des cubes ont plutot tendance à
utiliser une base répliquée et indexée très différemment pour ne pas
pénaliser les consultations et mises à jour interactives: là on est dans ce
cas directement pour ta base destinée au rendu local)

A voir aussi quel index tu as besoin de mettre en "cluster" de la table
principale et quel index tenir séparé : l'index primaire n'est pas
forcément (et en fait est rarement) le mieux à placer en cluster quand il
peut être beaucoup plus compact (un index primaire ne contient souvent que
la clé unique) Voir aussi comment cette table indexée est accédée: en mode
aléatoire par des jointures très sélectives depuis une autre table (dans ce
cas un index séparé est meilleur), ou bien par intervalle essentiellement
en mode séquentiel sur cette clé (là on a intérêt à utiliser le cluster sur
cet index).

Il n'y a pas de solution miracle: un audit de performance basé sur
l'utilisation réelle et des statistiques et sélectivité donne de meilleures
pistes qu'une simple estimation basée sur la volumétrie globale.

Autre piste à explorer: séparer les temps où la base sert à faire du rendu
et les temps où elle fait des mises à jour en intégrant les "diffs". Faire
les deux en même temps (dans des processes indépendants) peut être très
pénalisant. On doit pouvoir déterminer des seuils de tâches à faire donnant
priorité à un type de tâche ou à l'autre et inclure une fraction de temps
destinée à la maintenance de la base elle-même (surveillance du taux de
remplissage global des pages, ou mise à jour des pages statistiques de
sélectivité utilisées par l'optimiseur interne des plans d'exécutions de
requêtes).


Le 5 février 2017 à 16:05, Christian Quest  a
écrit :

> Un peu d'optimisation faite hier dans postgresql sur le serveur BANO, ou
> plus exactement du "debloating d'index" c'est à dire la regénération des
> index des données BANO qui a permis de gagner 80Go d'espace disque (sur
> 200).
>
> Ceci devrait nettement améliorer le temps de génération des tuiles BANO
> qui s'était fortement ralentit ces derniers temps...
>
> J'ai aussi rechargé les adresses BAN (en gris).
>
>
> --
> 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] intégration des référentiels STIF

[Noémie Lehuby]

 

Bonjour,

voici quelques nouvelles du projet d'intégration des ref STIF dans OSM :

CONCERNANT L'INTÉGRATION DES CODES STIF SUR LES LIGNES
Un petit état des lieux :
- 381 ref STIF intégrés dans OSM
- 57 lignes dans OSM sans ref STIF

L'outil est toujours dispo pour réaliser des comparaisons et intégrer
les ref : https://ref-lignes-stif.5apps.com/
C'est très facile, Florian qui a importé 80% de ces ref en une
demi-journée pourra en témoignera ;)
À noter que parmi les lignes restantes, il y en a encore sûrement qui
n'existent plus aujourd'hui et qui devraient être supprimées.

Ensuite, j'ai réalisé, avec l'aide Frédéric et de Jocelyn, une analyse
Osmose qui permet de renseigner quelques tags manquants sur les lignes
OSM en s'aidant des infos opendata : 
http://osmose.openstreetmap.fr/fr/errors/?source=28482=8042=1

C'est encore modeste, mais ça grossira avec l'avancement de
l'intégration des ref sur les lignes, et ça pourra également permettre
d'enrichir les relations route.

Par contre, d'après le STIF, on a plus de 1400 lignes en Île-de-France,
donc c'est loin d'être fini !

Il y a un effet un gros manque de lignes de transport (relation
route_master) dans OSM.
En revanche, en terme de parcours (relation route), on est plutôt pas
mal : on trouve pas mal de relation route où on a, en vrac, le tracé en
sens aller, le tracé en sens retour, un tracé spécial des jours de
marché, tous les arrêts et même quelques stop_position. En y remettant
un peu d'ordre, on peut créer une relation route_master et ses relations
route. J'en ai créé ainsi une petite trentaine depuis le début de
l'année.
Personnellement, je cartographie surtout du bus, mais le manque de
relation route_master est très général, il en manque sur la plupart des
RER et Transilien également.
Sur ce sujet, je n'ai pas d'idée de génie pour nous aider à avancer :
On doit pouvoir extraire les relations route non membre d'une relation
route_master pour isoler les éléments à créer, mais ça restera du
travail long et chiant à faire dans JOSM derrière :(

CONCERNANT L'INTÉGRATION DES CODES STIF SUR LES ARRÊTS
Les proposition d'intégration Osmose de Frédéric sont toujours
disponibles.
Attention tout de même au fait que

* un arrêt OSM peut porter plusieurs codes STIF
* les ref du STIF sont des ref de public_transport = platform et pas
de public_transport = stop_position.

Là encore, on a des petites lacunes : on a des lignes entières
(notamment de tram et de train) cartographiées uniquement avec des
stop_position, donc les codes STIF n'y ont pas trop de sens.

J'ai fait un prototype d'outil web qui facilite l'intégration des codes
STIF sur les arrêts d'une ligne (une fois que le code STIF de la ligne a
été renseigné), mais ce n'est pas encore prêt ...
La pérennité des codes STIF reste aussi à vérifier : j'ai trouvé des
codes STIF intégrés sur les arrêts avec Osmose qu'on ne retrouvait pas
dans la dernière version du référentiel du STIF.
Bref, c'est nettement moins avancé sur ce sujet (et je ne parle même pas
des codes STIF des zones d'arrêts :p), mais je ne m'en inquiète pas, ça
me parait plus efficace de se concentrer sur les lignes pour le moment.

Voilà pour le petit point d'étape.
Il y a toujours un salon de discussion avec des infos un peu plus
fréquentes ouvert ici : https://framateam.org/bato-fr/channels/stif 
Et s'il y a des gens motivés, on peut aussi en discuter de vive voix à
une prochaine rencontre mensuelle des contributeurs d'Île-de-France ;)

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

[OSM-talk-fr] Coup de turbo sur le rendu BANO...

[Christian Quest]

Un peu d'optimisation faite hier dans postgresql sur le serveur BANO, ou
plus exactement du "debloating d'index" c'est à dire la regénération des
index des données BANO qui a permis de gagner 80Go d'espace disque (sur
200).

Ceci devrait nettement améliorer le temps de génération des tuiles BANO qui
s'était fortement ralentit ces derniers temps...

J'ai aussi rechargé les adresses BAN (en gris).


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