[Addons] ESRI Shapefile import/export and georeferenced raster importer

Update:
Resolved the shape file issue. It had to do with the shapefile itself, which the importer didn’t like. I ‘cleaned’ it by running it ogr2ogr:
ogr2ogr -f “ESRI Shapefile” -overwrite -nlt POINT input.shp output.shp

Specifying the geometry type did the trick in my case.

I am trying to import a shapefile with a field for elevation. I get the error: “Elevation values aren’t numeric”. I have tried using the data types real, integer and even string, but no go. Any ideas?

Edit:
The above fails on the multipart “_shape object has no attribute parts” check. Will investigate later why.

Edit:

Also, when trying to import a png as DEM I am getting this error. It happens quite randomly.:

Traceback (most recent call last):
File “/home/g/.config/blender/2.69/scripts/addons/io_import_georaster.py”, line 609, in execute
displacer.strength = deltaZ/(deltaZ/2**depth)
UnboundLocalError: local variable ‘depth’ referenced before assignment

location: <unknown location>:-1

Hi domlysz,

That’s fantastic - merci beaucoup! Especially for implementing my request for geo-rendering! I will try this out and post some tests… :slight_smile:

Sorbus

Wow this work is great! I really appreciate the information in the pdf! It should have its own blender wiki page! Very clear and informing! Thanks for the work @domlysz!

Hi all,

Version 1.6 : Adding support for line & point layers extrusion on shapefile import

@freedumb2000
Now perform a purge of null geom when import shp to avoid “no attribute ‘parts’” error
“local variable ‘depth’ referenced before assignment” error on georeaster import now corrected

@Sorbus
Any feed back on georender tool ?

Hi Domlysz,

I won’t have time to do a proper test until next week due to coursework, but from a quick test projected data (OSGB) worked perfectly! Thank you again. I still had to manually adjust view clipping and move the camera’s Z location up away from 0.0. Lat lon data did not seem to import okay for me, however, I may have made some errors with it. A quick question: is the only chance to set pixel dimensions in map units when a new camera is created? Can exiting cameras be edited?

Cheers,

Sorbus

We have been applying an orthophoto to a TIN. Testing on multiple PCs with Linux OS and different versions of Blender in some we successfully import the georaster but not in others.
After much research we realized that the problem is to work with the Spanish language in Blender. Some tools change in the program when the script runs. This seems to affect the process.
In this picture I show two environments: in English and Spanish. As you can see, with this latest change or disappear dropdown lists and buttons.

Sorry I can not give many details because I’m newbie with Blender.


@egofer
It’s not a language problem, in your screenshoot left side uses original Blender renderer and right side uses Cycles it’s why you get differents options. With Cycles you need to enable nodes material to see the textures in the viewport.

@Sorbus
Thanks for the feedback, I never test the script with lat lon data, so I’ll consider the problem. Currently you cannot edit the camera maybe I can add some custom props to edit render resolution without recreate a camera.

Sorry I’m not sure exactly understand your question about pixel dimensions. Currently when you create a new cam you can set the pixel dimensions of the render output in map units, is this a problem? maybe you think to another easier way to set the render size? Another unit ?

Oops! Sorry for my stupidity. Like I said I’m starting with Blender and is a new world for me. However what I’m seeing so far I’m enjoying it a lot and your work with importers is really impressive.

Hi Domlysz,

Working with projected data only is fine for me. Perhaps you could mention this necessity in your readme file?

Setting the pixel size during camera creation is also fine - editing render dimensions afterwards is not a good idea, as you know! Rasters loaded back into GIS line up perfectly.


Works nicely with FreeStyle rendering too :slight_smile:

Some quirks still exist however:

  • I’ve only tested with a shapefile without heights, but I still need to manually move the camera up and set its clipping distance to render correctly.
  • When using multiple shapefiles, they must share the same dimension bounding box in GIS else they will be offset in Blender

These are not huge problems by any means, but would be nice updates if they were easy to solve.

Many thanks once again!

Sorbus

New version 1.7

There was a major issue in the way the script gets the image bit depth for DEM import. This problem caused a bad displacer strength value on some raster (too high, so the plane seems totally flat…).

Now the user needs to specify the bits depth, it’s more annoying but safer.

hi,

i’m trying to blender some terrains (especially mountains). for that i want to use the NASA data or the openDEM data (which as far as i know are the NASA data plus some enhancements). but i really dont get it to work with this addon :frowning: all i get are errors “there isn’t georef mesh to UVmap on” or in case of the shapefiles i get from openDEM i dont know how to shrink them to the section i actually want… i searched for step by step tutorials on google/youtube in english and german but found nothing that helped.

thanks in advance to everybody who can help!

here are the links to openDEM and the NASA data
http://opendem.info/opendem_client.html
http://earthexplorer.usgs.gov/

i now found this:


thats a very nice tutorial but with different methodes… and what you get is a STL so you can work with it in blender :wink:

but if still someone could help with this blender addon that would be great!

Hi Edelfisch,

For free DEMs try this resource: http://www.cgiar-csi.org/data/srtm-90m-digital-elevation-database-v4-1
OpenDEM seemed to be contour shapefiles only when I checked. CGIAR use NASA data and have cleaned it of a lot of errors.

Make sure that you import the DEM geotif with mode ‘On plane’ first, then ‘As DEM’ the second time.

As pointed out before on this thread, the plug-in requires the DEM has a bit of work done in a GIS program before import. Having a map projection rather than lat-lon coordinates helps, and be very careful with cells with ‘no data values’ which can really mess with the height of the terrain… :slight_smile:

there i get the error “unable to read world file” :frowning:

Hi,

Do you read the pdf doc ???

@Sorbus
New version version coming soon with support of lat long coords !

@domlysz Really nice addon you made here, thanks a lot :slight_smile:

Version 1.8, update of georaster import script :
-can convert lat long coords to meters
-auto compute DEM min/max statistics
-2 methods for get DEM displacement : setting displacer strength or setting object dimension Z (this way is more convenience)
-various bug correction (more accurate UVmap, better support of scaled dataset …)

pdf doc not yet update

Still working on this script : I study the way to use GDAL python binding instead of binary to deal with signed DEM dataset and nodata values, code cleanup also in progress

That’s an awesome addon! Thanks for your work, it’s very appreciated.

I haven’t had much time (yet) to get deeper into all the possibilities but I’ve got a question regarding the export of georeferenced images: Is it possible to export a georeferenced image just from a rendering?

For example, I have multiple 3D-models derived from laserscanning / photogrammetry (which were referenced in a different software, UTM coordinates clipped to 3 digits) and it would be nice to have a wld file for the rendered images. Is that possible? At the moment the field “Set georef cam” is blank.

Cheers!

Yes I think is possible, I also use custom values but for each objects, not scene. I can easily change this but there are some others things to consider :

Initialy I designed my tool to working with projected data in meters. The user must choose his projection system (depends on country) and must convert all his data in this system before import them in Blender.

Dealing with geo coords (long lat), like OSM data, isn’t trivial because it need to convert them to projected coords. To do this I chose the equirectangular projection because it’s the simplest way to convert geo coords in cartesian world. Equirectangular projection is also called “non-projection” because the horizontal coordinate is simply longitude, and the vertical coordinate is simply latitude, with no complex transformation applied (we just need to know earth radius to compute distance in meters of one degree…). It’s why it’s possible to maintain, in Blender, an effective relation between vector or raster data source in geographic coords system and mesh data in equirectangular coords sytem. But the disadvantage of this projection is that horizontal distortion increases as the distance from the equator increases.

vvoovv uses the Transverse Mercator (UTM) projection instead of equirectangular projection and UTM is a more complexe transformation. It’s not a big deal to convert vertex coords to UTM but for raster support, each pixel position needs to be recomputed to match UTM proj. So you cannot just get image corners coords and convert them to UTM to get an image in correct location, it’s totally wrong. vvoovv support SRTM raster data by creating vertex from pixels data, so it’s possible to reproject the coords on the fly and get correct UTM coords for each vertex.

So beyond custom properties, it’s essential to harmonize the choice of the projection system.

Ok, didn’t know it was more than the custom values. Thanks for the good explanation :slight_smile: I hope you can get the code for UTM from vvoovv pretty easily integrated in yours. By the way, OSM addon from campbell (in contrib, so in every buildbot) also has UTM projection. Maybe you will find one of the code better for your addon. Hope it helps, your contribution is much appreciated :slight_smile:

Just I a quick note.

I do use the transverse Mercator projection. But I don’t use UTM.

The UTM projection divides the earth surface into 60 fixed zones. The size distortion could be quite noticeable near the UTM zone border.

I use the transverse Mercator projection with dynamically calculated central meridian. The central meridian comes through the center of the imported area. The size distortion is negligible in the vicinity of the central meridian.