RFC108 - Heatmap/Interpolation Layer creation #4857
Conversation
|
Awesome addition! Now I can ditch some hacks I dropped into GDAL years ago and a processing chain that also included imagemagick. Got any samples? --Steve From: Thomas Bonfort [notifications@github.com] This issue tracks the development of RFC-108: http://mapserver.org/development/rfc/ms-rfc-108.html You can merge this Pull Request by running git pull https://github.com/tbonfort/mapserver heatmaps Or view, comment on, or merge it at: Commit Summary
File Changes
Patch Links:
— |
|
|
||
| free(values); | ||
| char ds_string [1024]; | ||
| snprintf(ds_string,1024,"MEM:::DATAPOINTER=%p,PIXELS=%u,LINES=%u,BANDS=1,DATATYPE=Byte,PIXELOFFSET=1,LINEOFFSET=%u", |
There was a problem hiding this comment.
@rouault could you please give a quick yes/no answer as to whether it is correct to use this method to create a GDAL datasource. i.e. can/should I be using the GDAL C api to create this datasource rather than making it parse this string ?
There was a problem hiding this comment.
Yes, this is valid. But when you create a MEM dataset this way, you remain the owner of the buffer. It is your responsibility to you to destroy it after the MEM dataset has been destroyed (the MEM dataset wouldn't know with which method to use to free the buffer).
If you want the MEM dataset to manage the buffer, then you should use GDALCreate().
also adds: - rfc86 scaletoken substitutions for PROCESSING entries - proj fastpaths for 3857->4326 reprojections
|
It works!!! |
|
Hi. I was just wondering if this feature could be used to plot a data grid. (And if not, whether it could be developed.) Or, imagine the SRTM (Surface Radar Terrain Model) data from NASA. It is also a rectangular grid of elevation data. Using this data one could draw an elevation map in MapServer. |
This issue tracks the development of RFC-108: http://mapserver.org/development/rfc/ms-rfc-108.html