Le portail francophone de la géomatique

Bonjour il y a le plugin OSM route. Mais il ne fait qu'une seule zone isochrone à la fois.

Bonjour groflo,

J'ai déjà eu l'occasion de me pencher sur ces questions. Postgre comme GRASS te permettront de la faire.
Pour ma part, j'ai porté mon choix final sur GRASS ... (apprentissage nécessaire !)

Il y a un tuto ici : http://www.ing.unitn.it/~grass/docs/tut … index.html
Voir aussi : https://grasswiki.osgeo.org/wiki/Vector … k_analysis

Il faut comprendre les logiques de connexions et graphes.

GRASS te permettra d'itérer sur chacun de tes points, le cas échéant.

Pour ce qui concerne tes isochrones "marche à pied", jettes un oeil sur : https://grass.osgeo.org/grass70/manuals/r.walk.html


Bon courage,

Dernière modification par simon_g (Sat 07 November 2015 13:17)

Pour ma part, essentiellement trois choses :

- une meilleure maîtrise de GRASS ;
- une diversité possible des traitements et rendus (vecteur / raster)
- possibilité d'analyses de réseau complémentaires

Bonjour,

Comme je ne travaille pas avec PostGre, le choix a été vite fait : Grass.
D'ailleurs j'avais fait un petit tuto (qui commence surement à dater) chez les voisins d'en face : http://www.forumsig.org/showthread.php/ … isochrones

je trouve l'outil très efficace, mais il manque juste une chose à mes yeux : la création des polygones englobant les différentes parties du réseau.

Vincent

Merci pour ce retour (et ce tuto ! effectivement, ça m'éclaire déjà).

En revanche, effectivement l'absence de polygone me semble assez limitant.

Du coup, PgRouting avec PostGIS semblerait, pour un rendu optimal, la meilleure solution.
Reste que j'ai l'impression (fausse, peut-être) que le coût d'entrée sur GRASS quand on est habitué à QGIS est moins important que PostGIS.

Dommage de n'avoir pas de retours de PostGISistes.
Mais merci à tous pour vos retours !

Salut,

On en parle pas souvent mais on peut arriver à de super résultats en calculant un raster de coût (module r.cost de GRASS accessible depuis processing dans QGIS).

Il y a évidement quelques inconvénients:
- globalement il y a pas mal d'étape et un peu de travail préparatoire pour mettre ne place une méthodo correcte (selon vos besoins et attentes), voir un script pour automatiser
- comme il faut convertir les données en raster, on ne peut pas prendre en compte certaines subtilités du réseau tel que sens unique, tunnel ou pont
- le temps de calcul peut rapidement exploser

En revanche je trouve la représentation en mode raster beaucoup plus pratique que des polygones isochrones. On peut faire une symbologie par coloration continue ou par classe (ce qui revient à la même chose que des polygones).

Dans QGIS on peut associé plusieurs styles à une couche est switcher rapidement de l'un à l'autre ce qui permet par exemple préparer des classifications selon différents intervalles (5 minutes, 10 minutes ...) et de passer d'une représentation à l'autre en 2 clics. Bref c'est extrêmement souple, et pour ceux qui veulent absolument des polygones il est toujours possible de les dériver du raster de coût.

Pour vous faire une idée plus précise voici en synthèse un exemple de méthodo:
1. récupérer une couche réseau, attribuer une vitesse en kmh selon le type de voie, avoir une couche avec les points de départ
2. rasteriser le réseaux en conservant la valeur de vitesse, choisir la résolution selon l'emprise de l'étude de façon à maintenir des temps de calculs acceptables (ex: 20m pour un département)
3.avec une calculatrice raster donner aux zones hors réseaux (no data) une valeur de vitesse (par ex 5kmh)
4.calculer le temps de parcours d'un pixel en minutes via la calculatrice raster et la formule  (distance * 60) / (vitesse * 1000) avec distance=résolution en mètre d'un pixel soit ici 20m
5.calculer le raster de coût (accumulation des valeurs "temps de parcours d'un pixel" depuis les points de départ; le raster obtenue sera en minutes
6.faire une symbologie par classe pour obtenir une représentation équivalente à des polygones isochrones

Ah oui v.isochrone propose un mode raster basé sur r.cost, je savais pas c'est super !

https://grass.osgeo.org/grass70/manuals … rones.html

Dernière modification par dominique.lys (Wed 18 November 2015 10:46)

Oui dans la 1ère video je montre comment :

-selectionner les types de voies utiles pour de l'isochronie automobile.
-affecter une valeur de vitesse à ces entités selon le type de voie.


Dans la video je propose un profil de vitesse à 50 pour cent (environ) de la valeur max autorisée.

Dans mon calcul qui est un exemple simple, je ne fais de distinguo entre agglo et hors agglo. Libre à toi de le mettre en place si tu le souhaites.
Quoi qu'il en soit, je t'invite à renseigner ton champ speed selon un profil de vitesse (70 %, 50%) car mes tests que j'avais fait en region parisienne basés sur la valeur max de vitesse me donnait des courbes isochrones avec une aire très (trop) étendue.

Ci dessous, de la doc OSM qui montre les caractéristiques de chaque type de road et ses max speed. Tu pourras egalement retrouver le distingo agglo/hors agglo:

http://wiki.openstreetmap.org/wiki/OSM_ … eed#France

http://wiki.openstreetmap.org/wiki/FR:K … e:maxspeed

http://wiki.openstreetmap.org/wiki/FR%3AKey%3Amaxspeed


Enfin, un lien issu du depot github  d'OSRM qui montre les types de voies selectionnés de de l'isochronie  automobile. Les valeurs de vitesses sont ici un profil à 80 pour cent.
Plus bas sur la page de code, tu verras, une petite partie traite justement je crois du distinguo agglo/hors agglo. Je crois OSM appelle celà plutot rural/urban :

https://github.com/Project-OSRM/osrm-ba … es/car.lua


Donc libre à toi de faire le distinguo agglo/hors agglo. Mais est ce qu'un champ de ta BD OSM renseigne sur cette caractéristique agglo / hors agglo?

Dernière modification par image95 (Thu 19 November 2015 14:43)

1/ Concernant OSM, dans ma video, je propose de récupérer la data via le site geofabrik qui offre une couche 'roads'. Mais geofabrik ne permet pas de récupérer l'intégralité de la data OSM. Par exemple, tu ne peux pas récupérer le bati via geofabrik.

Je pense que tu devrais faire un test de récupération de data OSM sur une zone via par exple l'application overpass turbo:

http://overpass-turbo.eu/

http://wiki.openstreetmap.org/wiki/Overpass_turbo

C'est une appli qui te permet de faire toutes les extractions que tu souhaites. Tu peux j'imagine ajouter la clef 'urban' ou 'rural'.
Par exple, j'avais reussi à extraire toutes les piscines privées de Corse. Ou encore tous les parkings publics de la region parisienne.


Si celà te semble trop compliqué dans un 1er temps, tu peux récupérer de la data OSM directement dans qgis via vecteur -> telecharger de la data OSM. Regarde si tu retrouves la variable urban/rural. j'imagine que tu peux egalement récupérer de la data OSM directement via le site officiel OSM.

Si tu veux plus d'info, je pense que tu aurais plus de retours via la mailing list FRANCE d'OSM :

http://gis.19327.n5.nabble.com/France-f5380434.html


2/ Je ne suis pas un expert d'isochronie. Je crois que la methode isochronie basée sur les valeurs max autorisées n'est pas la seule methode existante. En tout cas c'est une methode qui je pense est limitée en soi car elle ne se base que sur ces valeurs de vitesse. Et ne prends pas en compte par exple la congestion du traffic, les feux rouges...et d'autres paramètres.

J'imagine que des developpeurs ont du mettre en place des applis d'isochronie plus poussées permettant de prendre en compte ces paramètres.

Au début de cette chaine de discussion, un lien evoquait une appli web. REgarde un peu la discussion suivante:

http://www.owlapps.net/discussions

En mode navtek, j'avais fait un test sur l'idf et les courbes etaient vraiment pertinentes. Ce qui est sympa c'est que tu peux renseigner un jour et un horaire.

J'avais essayé de poster un message au developpeur. Mais j'avais pas eu de réponse.