Have you consider to use GRASS GIS analysis? I have expirience that GRASS algorithms have very good accurance on hydrology analysis. For example, I want to generate something like drainage network on DTM with resolution 5x5m. I had compared tools from ArcMap (including ArcHydro Tools) and you can view the result on first picture (red lines). Then I tried to ...
Martin is correct that while your workflow will do well for a specific user case, it doesn't account for many of the issues that road embankments create for flowpath modelling using fine-resolution LiDAR data, such as the problems with discontinuous flow in roadside ditches and the effects of minor unmapped culverts (which can alter flowpaths considerably). ...
With regard to generating hydrologicaly correct elevation models, also called drainage enforced, ANUDEM, remains best of breed to my knowledge. It's the program used to generate the Canadian national elevation dataset (CDED, ironically stored as integer-metres). Also the TopoToRaster tool in ArcGIS uses Anudem under the hood (a revision or three behind ...
I would simply use OGR's OSM Driver.
With this script you get a list of all the street names. I just tried it with a small sample dataset. I don't know how it will perform with a bigger one.
ds = ogr.Open('map.osm')
layer = ds.GetLayer(1) # layer 1 for ways
nameList = 
for feature in layer:
if feature.GetField("highway") != None:
Ok here is the image
Blue are the bridges from OSM.
The DEM is in grey-scale with buildings (I want buildings)
I selected the intersect roads that cross the bridges.
Buffered the selected roads by the approximate width of a road.
Ran 'Zonal Minimum' on the buffer.
Now you have the zonal minimum raster (red) with the low values.
The I just used CON to ...
This looks like a valid workflow for this task. However, depending on the level of accuracy that you work with, you will miss out on things like pipes under roads allowing for ditches and small creeks to flow past the road. These would probably require some field work to identify though.
You don't mention which software you use, but for ArcMap point (6) ...
If you do not care about what happens between your two ends (not that this is dangerous for long roads in hilly regions), here are the steps :
1) feature vertices to points (ask for START and for END)
2) extract values to points (for both sets of points, don't forget to check the "interpolate" box)
3) join by attributes (based on ID) the starts and the ...
The ST_Polygonize aggregate in PostGIS will return a geometry_dump containing all possible polygons formed by a set of lines. I'm assuming the block IDs shown in your example are not related to the IDs of input linework. If this is the case, you can get your polygons and IDs with:
SELECT (st_dump).path as poly_id, (st_dump).geom FROM
I think you'll need to georeference the base image and then capture your vector layers manually drawing over it.
This seems like a similar proccess: http://geo.nls.uk/urbhist/guides_vectorlayerqgis.html but not exactly what you are looking for.
If you're unfamiliar with georeferencing this looks like a good guide as well: http://qgis.spatialthoughts....
Back in college I worked on a project that did this quite well. I am not a hydrologist, nor did I finish the project (graduated), but you might want to check this out:
From what I recall, it worked fairly well. Its a free tool and may be just what you need.
Edit: After reading your question more carefully, I believe this is exactly the tool ...
Here's an approach that uses a temporary table to incrementally aggregate clusters together. I don't really care for the temporary table approach, but this seems to perform quite well as the number of lines increases (I have 1.2 M lines in my input).
This is the way!
Ok, i got a great feedback from Remi-C and now this works like charm:
Best non-topology solution ever.. it REALLY works fast and easy (believe me i tested lots of ways to do this):
--please add this function:
-- please create a universal sequence for unique ...
Such a slight systematic shift is usually due to a lack of datum transformation before reprojecting the data. You should test the different transformation and your data will overlap correctly. I can't tell which one is best for you based on the information provided, but you can test it relatively fast.
EDIT: if this doesn't work, you have two solutions: ...
Specifically to the question about using integer or floating point: Integer is best for speed, storage and avoids some kinds of drift due to rounding errors. However when using integer don't use meters for your Z (elevation) values! Change the vertical units to centimeters or millimeters, or keep them as meters and scale the values (multiply by 100 or 1000) ...
The steps outlined by radouxju worked great; I added a few more specifics to the process I followed.
1) Run Data management > Features > “Feature Vertices to Points” on centerline feature class twice – once for start and once for end
2) Run Spatial Analyst Tools > Extraction > “Extract Values to Points” on the start and end feature classes, choose “...
Yes, it is possible but not as straightforward as the question may indicate. Points are only one of many items needed. For example, you have the points but do you have the names, start and end point of a road distinguished, z-level information (one road may cross another but not have an intersection), one-way information, and so on? If you have points then ...
OpenStreetMap data is not really setup like that. If you're familiar with editing OSM you will know that to create a road it is a simple line. So any road width that is styled is purely for the style of the map and not an actual account of the width of the roads.
Having said that you may get lucky with a crazy OSM fanatic who might have gone around the ...
I've actually looked at a similar situation myself, except we were looking at it the other way around (adding pavement info to our addressed centerlines). What we came up with was that there were a few options:
You could do an overhaul of your data entirely and convert the roads to a set of linear referenced lines, meaning they have M values in addition to ...
I'm not exactly sure what your stack is, but I'd do this:
Load extract into PostGIS using osm2pgsql
Run a query like:
WHERE highway in ('motorway', 'trunk', 'primary', 'secondary', 'tertiary', 'pedestrian', 'unclassified', 'service')
(You're missing 'residential','living_street', 'track', plus all the '*_link' types, btw.)
Coming from someone who formerly worked with 9-1-1 data, the best answer would be: Use a combined geocoder. By using a combined geocoder, you can use your point data as a first pass, then fallback to street centerlines for a second pass if you got no hits with the point data.
Because you already have good point locations representing actual address ...
Some real example data (or at least a little less contrived) might help you to get answers that are more what you're looking for. However, with what you've shown, I'd say you have the option to either be "currently precise" and allow for future expansion, or be "inclusively precise". I'll explain.
Currently Precise (section B would be from 5 to 6)
Your question has an active research area and many papers are dedicated to extract the geometrical properies of street network from moving objects (vehicles etc).
For example see
Constructing street networks from GPS trajectories (PDF)
A comparison and evaluation of map construction algorithms using vehicle tracking data
Apart from street names which ...
I can see a couple of issues with the code.
graphDirector = QgsVectorLayerDirector(layer, -1, '', '', '', 3)
I believe that should be
graphDirector = QgsVectorLayerDirector(layer, -1, '', '', '', 2)
or (better - more explicit)
graphDirector = QgsVectorLayerDirector(layer, -1, '', '', '', QgsVectorLayerDirector.DirectionBoth)
Note that ...
Assuming I understand your question correctly...
If you know the range of the primary numbers (of the addresses) for each street/section and have coordinates of the street as it winds along, then interpolate by using the full length of each section.
For example: if you know the range of primary numbers to be 100-200, and you have addresses with primary ...
I very much doubt there is any such thing - SQL database servers aren't really suitable for this kind of public-facing surface. For example, Denial of Service attacks are usually pretty trivial to construct if you allow arbitrary SQL.
There are other APIs (e.g. the overpass API and nominatim) for OpenStreetMap, but not SQL.
We maintain two from and to fields. One is a theoretical range which covers the anticipated values that could exist along the segment; the second is a physical address range which contains the actual range of addresses that exist along the segment. For the physical range, we include the lowest and highest along a given segment but don't concern ourselves ...