[mapserver-users] Multi-Resolution Terrain Map File
Bob Basques
Bob.Basques at ci.stpaul.mn.us
Tue Dec 27 07:07:51 PST 2011
All,
Ok, probably a real hack (as in I'm not sure I want to admit it), but I took a different route with this.
Using our local coordinate system, I set up a templated grid folder for all the desired resolution layers with a tile index based system and keep this in a static form. Instead of keeping all the data separate and indexed, I keep an index template and just change the tiles as needed. I add new tiles into the tile set (same names, just overwrite the old ones) as they are built/become available. The underlying tiles are from all different sources and are only updated when they become available. If there is a new set of data available only those tiles are built and replaced in the tile set. The same tile index is reused repeatedly thereafter, only the actual tiles are updated. The result is a single layer, single pass dataset with mixed tiles being rendered as needed.
Now if I could just figure out how to economically blend the tiles together colorwise . . . always something though . . . :c)
bobb
>>> Rahkonen Jukka <Jukka.Rahkonen at mmmtike.fi> wrote:
Hi,
On possibility might be to prepare one tileindex which contains all the resolutions. It is a normal shapefile and it can be edited with any GIS program. When ready and saved the tileindex can be sorted with sortshape utility so that the course DEM tiles are in the beginning of the shapefile and more accurate ones on the bottom. This way the accurate DEM would be drawn on top of coarse and the result woul look good. However, it would mean double rendering in those areas with accurare DEM. It does not necessarily be unacceptable slow but for avoiding that you could cut holes into the polygons presenting the course data.
In practise I am not sure if Mapserver is reading the holes of tileindex polygons. Perhaps you should split the polygon into pieces and delete then the polygons which are overlapped with more accurate DEM.
It might be also good to use course DEM everywhere with small map scales. That could be done by making a scale dependent group layer. The first would use only SRTM and when zoomed in the other layer with edited tileindex would take place.
-Jukka Rahkonen-
Brent Fraser wrote:
> You could use the OFFSITE value in the higher resolution layer.
> Basically in this scheme, mapserver would render each layer, and any
> place with an OFFSITE value would show the value from the layer under
> it.
> A more basic problem is how do you want the elevation value to be
> rendered to a visible image? You could use GDAL to pre-process the
> SRTM DEMs (http://www.perrygeo.net/wordpress/?p=7), or use mapserver to
> classify the DEM values to colors on the fly.
> Best Regards,
> Brent Fraser
>> How do I construct a map file that can handle different resolutions of
>> terrain, with fallback to lower resolution when a no-value is found? In
>> Google Earth Fusion, I can specify multiple terrain sources and tell it
>> which value(s) represent missing data, and it will then process the
>> terrain, checking for availability of each type of terrain, falling back
>> if there isn't any in a geographic area and falling back if there is
>> missing data.
>>
>> For simple fallback based on area coverage, I can use a map file like the
>> one below (using 30 Arcsecond SRTM and 1 Arcsecond DTED). Now, what would
>> I need to do to have it use/interpolate data from the 30 Arcsecond values
>> when there is a missing data/NODATA/hole in the DTED? In the file below,
>> gdaltindex has been used to generate the coverage shapefiles.
>
>> The example below is a simple one, and it would be really helpful to be
>> able to have multiple terrain sources and a way to automatically fill
>> voids the same way that transparency works with raster image layers.
>> Specifying that terrain values are posts and not pixels would be good too,
>> but lower priority.
>
> Xander
>
> MAP
> NAME "srtm"
> EXTENT -180 -90 180 90
> SIZE 512 512
> UNITS DD
> IMAGETYPE bil
>
> PROJECTION
> "init=epsg:4326"
> END
>
> OUTPUTFORMAT
> NAME "bil"
> DRIVER "GDAL/EHdr"
> MIMETYPE "image/bil"
> EXTENSION "bil"
> IMAGEMODE INT16
> END
>
> OUTPUTFORMAT
> NAME "bil16"
> DRIVER "GDAL/EHdr"
> MIMETYPE "application/bil16"
> EXTENSION "bil"
> IMAGEMODE INT16
> END
>
> OUTPUTFORMAT
> NAME "gtiff_16"
> DRIVER "GDAL/GTiff"
> MIMETYPE "image/tiff"
> EXTENSION "tif"
> IMAGEMODE INT16
> END
>
> WEB
> IMAGEPATH "/tmp/"
> IMAGEURL "/tmp/"
> LOG "/tmp/srtm.err"
> METADATA
> wms_title "SRTM Terrain"
> END
> END
>
> #
> # Coarse (30 ArcSecond) terrain. There is worldwide coverage, so this
> # is good for areas uncovered by SRTM data, as well as for high
> # scale values.
> #
> LAYER
> NAME "srtm"
> TILEINDEX "SRTM30/bathmetry.shp"
> TYPE RASTER
> PROCESSING "RESAMPLE=BICUBIC"
> STATUS ON
>
> METADATA
> "wms_title" "SRTM 30 ArcSecond Bathmetry"
> "wms_group_title" "srtm30"
> "wms_srs" "epsg:4326"
> "wms_style" "Default"
> "wms_extent" "-180 -90 180 90"
> END
>
> MAXSCALEDENOM 1000000000
> MINSCALEDENOM 10
> END
>
> #
> # Moderate resolution (1 ArcSecond) terrain. Coverage is available
> worldwide
> # for most land areas between latitudes -60 and +60.
> #
> LAYER
> NAME "srtm"
> TILEINDEX "srt2f_1/srt2f_1.shp"
> TYPE RASTER
> PROCESSING "RESAMPLE=BICUBIC"
> STATUS ON
>
> METADATA
> "wms_title" "SRTM 1 ArcSecond Bathmetry"
> "wms_group_title" "srtm30"
> "wms_srs" "epsg:4326"
> "wms_style" "Default"
> "wms_extent" "-180 -60 180 60"
> END
>
> MAXSCALEDENOM 1000000
> END
>
> END
>
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>
_______________________________________________
mapserver-users mailing list
mapserver-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
_______________________________________________
mapserver-users mailing list
mapserver-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20111227/ce5fe976/attachment.htm>
More information about the MapServer-users
mailing list