[gdal-dev] Multiple extensions in GDAL_DMD_EXTENSION ?
Is it possible to specify multiple file extensions in GDAL_DMD_EXTENSION ? I ask because I am working on a driver for a format that has several known file extensions. - Oyvind ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] To know about centriod of a polygon shape file
Siva, Centroid of a polygon need not coincide with the centroid of it's buffer. On Tue, Feb 19, 2013 at 11:21 AM, SIVA RAMA KRISHNA s.r.kriis...@gmail.comwrote: Dear All, I am just working on Shape files I am unable to detect duplicate centroids in a shape file .After buffering a polygon does centroids of both will match Any help in greatly appreciated With Regards ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL/OGR 1.10.0 Beta1
Hello, The announcement of GDAL/OGR 1.10 beta1 almost a month ago spawned only a few comments regarding EXIF metadata. I apologize for not having the time to test it myself, but is there a RC lurking around the corner? Sjur :-) -Original Message- From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev- boun...@lists.osgeo.org] On Behalf Of Frank Warmerdam Sent: 21. januar 2013 21:37 To: gdal dev Subject: [gdal-dev] GDAL/OGR 1.10.0 Beta1 Folks, A month or more later than I intended, I have prepared a GDAL/OGR 1.10 first beta release. http://download.osgeo.org/gdal/gdal-1.10.0beta1.tar.gz The NEWS for the release can be found at the top of: http://svn.osgeo.org/gdal/trunk/gdal/NEWS Please do some testing and file bugs for issues that need to be fixed. Also feel free to make noise on existing bugs that ought to be fixed before 1.10 is released. I hope to do another beta or two and then a release candidate. Best regards, -- ---+ ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Transform from ground control points
Hi I have an image with 4 control points at the 4 corners. From my understanding, this defines a perspective linear transform (not necesserally affine). I'm trying to warp it into an orthophoto. from what I see in the gdalgcptransform code it seems that only an affine transform is created. Is it the correct way of doing this projection, or is gdalgcptransform not the correct way of doing it? thanks yehiyam livneh This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE SYSTEMS LTD. (hereinafter RAFAEL) contains confidential information intended for a specific individual and purpose, may constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not the intended recipient, you should contact us immediately and thereafter delete this message from your system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, please notify us immediately by e-mail mailto:law...@rafael.co.il and completely delete or destroy any and all electronic or other copies of the original message and any attachments thereof. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Multiple extensions in GDAL_DMD_EXTENSION ?
I am not aware of a way to list multiple extensions. Best regards, On Feb 19, 2013 2:15 AM, Oyvind Idland oyvind.idl...@gmail.com wrote: Is it possible to specify multiple file extensions in GDAL_DMD_EXTENSION ? I ask because I am working on a driver for a format that has several known file extensions. - Oyvind ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Multiple extensions in GDAL_DMD_EXTENSION ?
It would be nice to be able to specify many extensions in a comma-separated list such as nc,cdf,nc4. It can probably be done (metadata is just a string), but isn't standard. The Gdal driver tutorial states: GDAL_DMD_EXTENSION: The extension used for files of this type. If more than one pick the primary extension, or none at all. (optional) It could be beneficial to extend this definition for multiple extensions separated by comma. cheers Etienne On Tue, Feb 19, 2013 at 11:26 AM, Frank Warmerdam warmer...@pobox.com wrote: I am not aware of a way to list multiple extensions. Best regards, On Feb 19, 2013 2:15 AM, Oyvind Idland oyvind.idl...@gmail.com wrote: Is it possible to specify multiple file extensions in GDAL_DMD_EXTENSION ? I ask because I am working on a driver for a format that has several known file extensions. - Oyvind ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Multiple extensions in GDAL_DMD_EXTENSION ?
For backward compability, an additional variable (eg. GDAL_DMD_EXTENSION_ALT or something like that) could be added with a specified format. - Oyvind On Tue, Feb 19, 2013 at 6:39 PM, Etienne Tourigny etourigny@gmail.comwrote: It would be nice to be able to specify many extensions in a comma-separated list such as nc,cdf,nc4. It can probably be done (metadata is just a string), but isn't standard. The Gdal driver tutorial states: GDAL_DMD_EXTENSION: The extension used for files of this type. If more than one pick the primary extension, or none at all. (optional) It could be beneficial to extend this definition for multiple extensions separated by comma. cheers Etienne On Tue, Feb 19, 2013 at 11:26 AM, Frank Warmerdam warmer...@pobox.com wrote: I am not aware of a way to list multiple extensions. Best regards, On Feb 19, 2013 2:15 AM, Oyvind Idland oyvind.idl...@gmail.com wrote: Is it possible to specify multiple file extensions in GDAL_DMD_EXTENSION ? I ask because I am working on a driver for a format that has several known file extensions. - Oyvind ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Multiple extensions in GDAL_DMD_EXTENSION ?
On Tue, Feb 19, 2013 at 9:39 AM, Etienne Tourigny etourigny@gmail.com wrote: It would be nice to be able to specify many extensions in a comma-separated list such as nc,cdf,nc4. It can probably be done (metadata is just a string), but isn't standard. The Gdal driver tutorial states: GDAL_DMD_EXTENSION: The extension used for files of this type. If more than one pick the primary extension, or none at all. (optional) It could be beneficial to extend this definition for multiple extensions separated by comma. Etienne, The challenge is to do this without breaking lots of applications that expect it to be a single extension. If we were to pursue this, I'd almost prefer to add GDAL_DMD_EXTENSION_LIST as a list of extensions that relate to this driver, and GDAL_DMD_EXTENSION would be the primary or preferred extension. But I'm still not all that keen. I see the GDAL_DMD_EXTENSION as existing primarily so that applications can prepare a reasonable default filename when creating a file. For this having a list of extensions is not helpful. People *usually* want a list of extensions so they can automatically categorize the format of files on disk or to filter to only show extensions they think GDAL supports. I find this practice abhorrent! GDAL is based on the idea that file formats are discovered by inspecting file contents rather than based on extension and I don't want to make it too easy for applications to ignore this principle and revert to extensions. One other use that extensions are used for is to make it easy for a user to filter down files in a file browser to just one format. I can't think of any time I've found this useful. But with GDAL there are so many formats that these list of formats filter dohickyies are usually completely unusable. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdal_polygonize and polygon edges
Hi, I'm using gdal_polygonize.py http://gdal.org/gdal_polygonize.html to create polygon from a grid and the output polygons seems to follow the edges of the grid pixels. I was wondering if there is any way to change/edit the code to instead of following the edges of the pixels, use the center of the pixels as the nodes of the created polygons ? So instead of a polygon following the edges of the pixels, it will instead be passing through the center of the connected pixels... This is to avoid having a scale effect of following the pixels edges. Thanks Jeff ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_polygonize and polygon edges
On Tue, Feb 19, 2013 at 10:29 AM, Jeff Lacoste jefflacosteg...@gmail.com wrote: Hi, I'm using gdal_polygonize.py to create polygon from a grid and the output polygons seems to follow the edges of the grid pixels. I was wondering if there is any way to change/edit the code to instead of following the edges of the pixels, use the center of the pixels as the nodes of the created polygons ? So instead of a polygon following the edges of the pixels, it will instead be passing through the center of the connected pixels... This is to avoid having a scale effect of following the pixels edges. Jeff, With the current algorithm, this is not really possible. I am also not clear what it would mean to go from pixel center to pixel center. The algorithm attempts to identify the borders between regions of different pixel values and turn them into polygons. What does it mean to make a polygon boundary that goes through the center of a pixel with a particular value? Another algorithm you might want to keep in mind is the contour generator. It treats the the raster values as a continuous field, and builds edges based on linear interpolation between pixel centers. This gives a result that could pass through a pixel center if it happens to be an exact contour level. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_polygonize and polygon edges
Hi Frank, Thanks for your quick response. Following the edges of the pixels seems a perfect solution for non continuous grid (ex. land use, etc.) as the boundary between the class is important to keep when constructing the polygon. However for continuous grid (.ex elevations), the boundaries are a bit not clear and not clear cut. When following the pixels edges, the created polygons appear to have the stairs effect and are less visually attractive. I thought of a smoothing the polygons to not have *rough* edges using the current gdal_polygonize by trying to not follow the pixels edges and use instead of the pixel centers. Basically do something similar to what contour generator does by treating the raster values as continuous. Thanks On Tue, Feb 19, 2013 at 1:44 PM, Frank Warmerdam warmer...@pobox.comwrote: On Tue, Feb 19, 2013 at 10:29 AM, Jeff Lacoste jefflacosteg...@gmail.com wrote: Hi, I'm using gdal_polygonize.py to create polygon from a grid and the output polygons seems to follow the edges of the grid pixels. I was wondering if there is any way to change/edit the code to instead of following the edges of the pixels, use the center of the pixels as the nodes of the created polygons ? So instead of a polygon following the edges of the pixels, it will instead be passing through the center of the connected pixels... This is to avoid having a scale effect of following the pixels edges. Jeff, With the current algorithm, this is not really possible. I am also not clear what it would mean to go from pixel center to pixel center. The algorithm attempts to identify the borders between regions of different pixel values and turn them into polygons. What does it mean to make a polygon boundary that goes through the center of a pixel with a particular value? Another algorithm you might want to keep in mind is the contour generator. It treats the the raster values as a continuous field, and builds edges based on linear interpolation between pixel centers. This gives a result that could pass through a pixel center if it happens to be an exact contour level. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_polygonize and polygon edges
On Tue, Feb 19, 2013 at 11:28 AM, Jeff Lacoste jefflacosteg...@gmail.com wrote: Hi Frank, Thanks for your quick response. Following the edges of the pixels seems a perfect solution for non continuous grid (ex. land use, etc.) as the boundary between the class is important to keep when constructing the polygon. However for continuous grid (.ex elevations), the boundaries are a bit not clear and not clear cut. When following the pixels edges, the created polygons appear to have the stairs effect and are less visually attractive. I thought of a smoothing the polygons to not have *rough* edges using the current gdal_polygonize by trying to not follow the pixels edges and use instead of the pixel centers. Basically do something similar to what contour generator does by treating the raster values as continuous. Jeff, Ah, I see, you are looking for visually attractive polygons from continuous fields. I have wondered if it would be reasonable to produce a version of the contour generator that actually produces polygon regions. If we had that then applying appropriate simplification to the resulting very detailed edges should give something attractive and with reasonable information density. An appropriate simplification algorithm might do this in a reasonable way for the existing polygonize output but I don't know enough about the simplification algorithms to suggest one. I don't think aiming for pixel centers in gdal_polygonize would really solve the problem. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_polygonize and polygon edges
Yes visually attractive or smooth polygons is the goal. Thanks again Frank. Doing a web search about simplification algorithm i found one named '*Ramer-Douglas–Peucker' (*http://en.wikipedia.org/wiki/Ramer-Douglas-Peucker_algorithm). It appears that 'Geos'' library implement this algorithm. Is this algorithm exposed through OGR ? Could this algorithm help smoothing a polygon without necessary make the new nodes too far from the original one ? Or may be there are other *more* recommended algorithms ? If any one could suggest a simplification algorithm or had some experience with smoothing polygons, I appreciate their input. Thanks Jeff On Tue, Feb 19, 2013 at 2:42 PM, Frank Warmerdam warmer...@pobox.comwrote: On Tue, Feb 19, 2013 at 11:28 AM, Jeff Lacoste jefflacosteg...@gmail.com wrote: Hi Frank, Thanks for your quick response. Following the edges of the pixels seems a perfect solution for non continuous grid (ex. land use, etc.) as the boundary between the class is important to keep when constructing the polygon. However for continuous grid (.ex elevations), the boundaries are a bit not clear and not clear cut. When following the pixels edges, the created polygons appear to have the stairs effect and are less visually attractive. I thought of a smoothing the polygons to not have *rough* edges using the current gdal_polygonize by trying to not follow the pixels edges and use instead of the pixel centers. Basically do something similar to what contour generator does by treating the raster values as continuous. Jeff, Ah, I see, you are looking for visually attractive polygons from continuous fields. I have wondered if it would be reasonable to produce a version of the contour generator that actually produces polygon regions. If we had that then applying appropriate simplification to the resulting very detailed edges should give something attractive and with reasonable information density. An appropriate simplification algorithm might do this in a reasonable way for the existing polygonize output but I don't know enough about the simplification algorithms to suggest one. I don't think aiming for pixel centers in gdal_polygonize would really solve the problem. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_polygonize and polygon edges
Jeff, I believe this is exposed in ogr2ogr using the -simplify argument: -simplify tolerance: (starting with GDAL 1.9.0) distance tolerance for simplification. Note: the algorithm used preserves topology per feature, in particular for polygon geometries, but not for a whole layer. Best regards, Frank On Tue, Feb 19, 2013 at 12:12 PM, Jeff Lacoste jefflacosteg...@gmail.com wrote: Yes visually attractive or smooth polygons is the goal. Thanks again Frank. Doing a web search about simplification algorithm i found one named 'Ramer-Douglas–Peucker' (http://en.wikipedia.org/wiki/Ramer-Douglas-Peucker_algorithm). It appears that 'Geos'' library implement this algorithm. Is this algorithm exposed through OGR ? Could this algorithm help smoothing a polygon without necessary make the new nodes too far from the original one ? Or may be there are other *more* recommended algorithms ? If any one could suggest a simplification algorithm or had some experience with smoothing polygons, I appreciate their input. Thanks Jeff On Tue, Feb 19, 2013 at 2:42 PM, Frank Warmerdam warmer...@pobox.com wrote: On Tue, Feb 19, 2013 at 11:28 AM, Jeff Lacoste jefflacosteg...@gmail.com wrote: Hi Frank, Thanks for your quick response. Following the edges of the pixels seems a perfect solution for non continuous grid (ex. land use, etc.) as the boundary between the class is important to keep when constructing the polygon. However for continuous grid (.ex elevations), the boundaries are a bit not clear and not clear cut. When following the pixels edges, the created polygons appear to have the stairs effect and are less visually attractive. I thought of a smoothing the polygons to not have *rough* edges using the current gdal_polygonize by trying to not follow the pixels edges and use instead of the pixel centers. Basically do something similar to what contour generator does by treating the raster values as continuous. Jeff, Ah, I see, you are looking for visually attractive polygons from continuous fields. I have wondered if it would be reasonable to produce a version of the contour generator that actually produces polygon regions. If we had that then applying appropriate simplification to the resulting very detailed edges should give something attractive and with reasonable information density. An appropriate simplification algorithm might do this in a reasonable way for the existing polygonize output but I don't know enough about the simplification algorithms to suggest one. I don't think aiming for pixel centers in gdal_polygonize would really solve the problem. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_polygonize and polygon edges
Thank you Frank ! Very much appreciated. I'll give 'Simplify' option a try. Jeff On Tue, Feb 19, 2013 at 3:25 PM, Frank Warmerdam warmer...@pobox.comwrote: Jeff, I believe this is exposed in ogr2ogr using the -simplify argument: -simplify tolerance: (starting with GDAL 1.9.0) distance tolerance for simplification. Note: the algorithm used preserves topology per feature, in particular for polygon geometries, but not for a whole layer. Best regards, Frank On Tue, Feb 19, 2013 at 12:12 PM, Jeff Lacoste jefflacosteg...@gmail.com wrote: Yes visually attractive or smooth polygons is the goal. Thanks again Frank. Doing a web search about simplification algorithm i found one named 'Ramer-Douglas–Peucker' (http://en.wikipedia.org/wiki/Ramer-Douglas-Peucker_algorithm). It appears that 'Geos'' library implement this algorithm. Is this algorithm exposed through OGR ? Could this algorithm help smoothing a polygon without necessary make the new nodes too far from the original one ? Or may be there are other *more* recommended algorithms ? If any one could suggest a simplification algorithm or had some experience with smoothing polygons, I appreciate their input. Thanks Jeff On Tue, Feb 19, 2013 at 2:42 PM, Frank Warmerdam warmer...@pobox.com wrote: On Tue, Feb 19, 2013 at 11:28 AM, Jeff Lacoste jefflacosteg...@gmail.com wrote: Hi Frank, Thanks for your quick response. Following the edges of the pixels seems a perfect solution for non continuous grid (ex. land use, etc.) as the boundary between the class is important to keep when constructing the polygon. However for continuous grid (.ex elevations), the boundaries are a bit not clear and not clear cut. When following the pixels edges, the created polygons appear to have the stairs effect and are less visually attractive. I thought of a smoothing the polygons to not have *rough* edges using the current gdal_polygonize by trying to not follow the pixels edges and use instead of the pixel centers. Basically do something similar to what contour generator does by treating the raster values as continuous. Jeff, Ah, I see, you are looking for visually attractive polygons from continuous fields. I have wondered if it would be reasonable to produce a version of the contour generator that actually produces polygon regions. If we had that then applying appropriate simplification to the resulting very detailed edges should give something attractive and with reasonable information density. An appropriate simplification algorithm might do this in a reasonable way for the existing polygonize output but I don't know enough about the simplification algorithms to suggest one. I don't think aiming for pixel centers in gdal_polygonize would really solve the problem. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_polygonize and polygon edges
Hi Jeff, FYI we have been working on smoothing contours produced by gdal_contour, and one of the issues that we encountered was having to deal with that same stair effect (even with contours we get it in some cases). I don't think that simplifying your polygons will be enough in your case, you really need to do some smoothing, possibly combined with some level of simplification (or not) depending on the scale at which you look at the data (this is what we found anyway). We found the following article describing a Smoothing via Iterative Averaging technique: http://www.ijcee.org/papers/501-P063.pdf this technique is kind of simple but we found that it works better than others on contours produced by sampling raster input like GDAL does. For instance, bezier curves may sound like the obvious asnwer but they tend to create overshoots in some situations which resulted in countours crossing each other. We ended up with an algorithm based on this SIA technique (plus a few tweaks) which smooths the stair effects and tends to pass close to the orginal points in most cases and most importantly does not produce crossing contours. We are going to share our code and results in the coming months (this was done for MapServer), we are just not ready yet unfortunately. Daniel On 13-02-19 3:12 PM, Jeff Lacoste wrote: Yes visually attractive or smooth polygons is the goal. Thanks again Frank. Doing a web search about simplification algorithm i found one named '*Ramer-Douglas–Peucker' (*http://en.wikipedia.org/wiki/Ramer-Douglas-Peucker_algorithm). It appears that 'Geos'' library implement this algorithm. Is this algorithm exposed through OGR ? Could this algorithm help smoothing a polygon without necessary make the new nodes too far from the original one ? Or may be there are other *more* recommended algorithms ? If any one could suggest a simplification algorithm or had some experience with smoothing polygons, I appreciate their input. Thanks Jeff On Tue, Feb 19, 2013 at 2:42 PM, Frank Warmerdam warmer...@pobox.com mailto:warmer...@pobox.com wrote: On Tue, Feb 19, 2013 at 11:28 AM, Jeff Lacoste jefflacosteg...@gmail.com mailto:jefflacosteg...@gmail.com wrote: Hi Frank, Thanks for your quick response. Following the edges of the pixels seems a perfect solution for non continuous grid (ex. land use, etc.) as the boundary between the class is important to keep when constructing the polygon. However for continuous grid (.ex elevations), the boundaries are a bit not clear and not clear cut. When following the pixels edges, the created polygons appear to have the stairs effect and are less visually attractive. I thought of a smoothing the polygons to not have *rough* edges using the current gdal_polygonize by trying to not follow the pixels edges and use instead of the pixel centers. Basically do something similar to what contour generator does by treating the raster values as continuous. Jeff, Ah, I see, you are looking for visually attractive polygons from continuous fields. I have wondered if it would be reasonable to produce a version of the contour generator that actually produces polygon regions. If we had that then applying appropriate simplification to the resulting very detailed edges should give something attractive and with reasonable information density. An appropriate simplification algorithm might do this in a reasonable way for the existing polygonize output but I don't know enough about the simplification algorithms to suggest one. I don't think aiming for pixel centers in gdal_polygonize would really solve the problem. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com mailto:warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette http://www.mapgears.com/ Provider of Professional MapServer Support since 2000 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_polygonize and polygon edges
It all depends on the data your having gdal_polygonize contour ... here is a snippet of what I'm doing with a csv I'm creating of current weather /usr/local/bin/gdal_grid -zfield temp -a invdist:power=2.0:smoothing=1:nodata=- -outsize 800 600 -l temp /var/www/html/metar/temp.vrt /var/www/html/metar/temp.tif python /usr/local/bin/gdal_polygonize.py /var/www/html/metar/temp.tif -f ESRI Shapefile /var/www/html/metar/temp/temp.shp temp temp and then the resulting shapefile is used to create the following http://www.michiganwxsystem.com/maps/curfore/ I have messed around with the 'power' and 'smoothing' settings these seem the remove the stair steps quite well - -Jeff Lake MichiganWxSystem.com AllisonHouse.com TheWeatherCenter.net GRLevelXStuff.com On 2/19/2013 15:12, Jeff Lacoste wrote: Yes visually attractive or smooth polygons is the goal. Thanks again Frank. Doing a web search about simplification algorithm i found one named '*Ramer-Douglas--Peucker' (*http://en.wikipedia.org/wiki/Ramer-Douglas-Peucker_algorithm). It appears that 'Geos'' library implement this algorithm. Is this algorithm exposed through OGR ? Could this algorithm help smoothing a polygon without necessary make the new nodes too far from the original one ? Or may be there are other *more* recommended algorithms ? If any one could suggest a simplification algorithm or had some experience with smoothing polygons, I appreciate their input. Thanks Jeff On Tue, Feb 19, 2013 at 2:42 PM, Frank Warmerdam warmer...@pobox.com mailto:warmer...@pobox.com wrote: On Tue, Feb 19, 2013 at 11:28 AM, Jeff Lacoste jefflacosteg...@gmail.com mailto:jefflacosteg...@gmail.com wrote: Hi Frank, Thanks for your quick response. Following the edges of the pixels seems a perfect solution for non continuous grid (ex. land use, etc.) as the boundary between the class is important to keep when constructing the polygon. However for continuous grid (.ex elevations), the boundaries are a bit not clear and not clear cut. When following the pixels edges, the created polygons appear to have the stairs effect and are less visually attractive. I thought of a smoothing the polygons to not have *rough* edges using the current gdal_polygonize by trying to not follow the pixels edges and use instead of the pixel centers. Basically do something similar to what contour generator does by treating the raster values as continuous. Jeff, Ah, I see, you are looking for visually attractive polygons from continuous fields. I have wondered if it would be reasonable to produce a version of the contour generator that actually produces polygon regions. If we had that then applying appropriate simplification to the resulting very detailed edges should give something attractive and with reasonable information density. An appropriate simplification algorithm might do this in a reasonable way for the existing polygonize output but I don't know enough about the simplification algorithms to suggest one. I don't think aiming for pixel centers in gdal_polygonize would really solve the problem. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com mailto:warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam http://pobox.com/%7Ewarmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] ogr utilities -dsco
OK GDAL Devs, I give up. If I want to specify multiple -dsco key:value with OGR, what is the syntax? This works for one attribute: R:\mpcaogr2ogr -f KML impaired_streams_2010.kml impaired_2010_streams.shp -ds co NameField=AUID But none of these work for two attributes: R:\mpcaogr2ogr -f KML test.kml impaired_2010_streams.shp -dsco NameField=AUID,DescriptionField=REACH_DESC R:\mpcaogr2ogr -f KML test2.kml impaired_2010_streams.shp -dsco NameField=AUID DescriptionField=REACH_DESC FAILURE: Couldn't fetch requested layer 'DescriptionField=REACH_DESC'! R:\mpcaogr2ogr -f KML test2.kml impaired_2010_streams.shp -dsco NameField=AUID DescriptionField=REACH_DESC R:\mpcaogr2ogr -f KML test3.kml impaired_2010_streams.shp -dsco NameField=AUID -dsco DescriptionField=REACH_DESC R:\mpcaogr2ogr -f KML test4.kml impaired_2010_streams.shp -dsco NameField=AUID,DescriptionField=REACH_DESC Thanks, David. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr utilities -dsco
Use one -dsco flag for each option: ogr2ogr -f KML impaired_streams_2010.kml impaired_2010_streams.shp -dsco NameField=AUID -dsco DescriptionField=REACH_DESC On Tue, Feb 19, 2013 at 2:26 PM, David Fawcett david.fawc...@gmail.com wrote: OK GDAL Devs, I give up. If I want to specify multiple -dsco key:value with OGR, what is the syntax? This works for one attribute: R:\mpcaogr2ogr -f KML impaired_streams_2010.kml impaired_2010_streams.shp -ds co NameField=AUID But none of these work for two attributes: R:\mpcaogr2ogr -f KML test.kml impaired_2010_streams.shp -dsco NameField=AUID,DescriptionField=REACH_DESC R:\mpcaogr2ogr -f KML test2.kml impaired_2010_streams.shp -dsco NameField=AUID DescriptionField=REACH_DESC FAILURE: Couldn't fetch requested layer 'DescriptionField=REACH_DESC'! R:\mpcaogr2ogr -f KML test2.kml impaired_2010_streams.shp -dsco NameField=AUID DescriptionField=REACH_DESC R:\mpcaogr2ogr -f KML test3.kml impaired_2010_streams.shp -dsco NameField=AUID -dsco DescriptionField=REACH_DESC R:\mpcaogr2ogr -f KML test4.kml impaired_2010_streams.shp -dsco NameField=AUID,DescriptionField=REACH_DESC Thanks, David. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr utilities -dsco
David, This should have worked. ogr2ogr -f KML test3.kml impaired_2010_streams.shp -dsco NameField=AUID -dsco DescriptionField=REACH_DESC Did one of the options get ignored? Was there an error? Best regards, Frank On Tue, Feb 19, 2013 at 1:26 PM, David Fawcett david.fawc...@gmail.com wrote: OK GDAL Devs, I give up. If I want to specify multiple -dsco key:value with OGR, what is the syntax? This works for one attribute: R:\mpcaogr2ogr -f KML impaired_streams_2010.kml impaired_2010_streams.shp -ds co NameField=AUID But none of these work for two attributes: R:\mpcaogr2ogr -f KML test.kml impaired_2010_streams.shp -dsco NameField=AUID,DescriptionField=REACH_DESC R:\mpcaogr2ogr -f KML test2.kml impaired_2010_streams.shp -dsco NameField=AUID DescriptionField=REACH_DESC FAILURE: Couldn't fetch requested layer 'DescriptionField=REACH_DESC'! R:\mpcaogr2ogr -f KML test2.kml impaired_2010_streams.shp -dsco NameField=AUID DescriptionField=REACH_DESC R:\mpcaogr2ogr -f KML test3.kml impaired_2010_streams.shp -dsco NameField=AUID -dsco DescriptionField=REACH_DESC R:\mpcaogr2ogr -f KML test4.kml impaired_2010_streams.shp -dsco NameField=AUID,DescriptionField=REACH_DESC Thanks, David. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_polygonize and polygon edges
a few years ago someone had posted some perl code for making polys from the contour output. the idea was to sort the lines into an m-way tree by contains with the root node being the extent of the data then each node would be outer ring and a copy of the children being the inner rings i have done this myself and it works Brian On Tue, 2013-02-19 at 14:28 -0500, Jeff Lacoste wrote: Hi Frank, Thanks for your quick response. Following the edges of the pixels seems a perfect solution for non continuous grid (ex. land use, etc.) as the boundary between the class is important to keep when constructing the polygon. However for continuous grid (.ex elevations), the boundaries are a bit not clear and not clear cut. When following the pixels edges, the created polygons appear to have the stairs effect and are less visually attractive. I thought of a smoothing the polygons to not have *rough* edges using the current gdal_polygonize by trying to not follow the pixels edges and use instead of the pixel centers. Basically do something similar to what contour generator does by treating the raster values as continuous. Thanks On Tue, Feb 19, 2013 at 1:44 PM, Frank Warmerdam warmer...@pobox.com wrote: On Tue, Feb 19, 2013 at 10:29 AM, Jeff Lacoste jefflacosteg...@gmail.com wrote: Hi, I'm using gdal_polygonize.py to create polygon from a grid and the output polygons seems to follow the edges of the grid pixels. I was wondering if there is any way to change/edit the code to instead of following the edges of the pixels, use the center of the pixels as the nodes of the created polygons ? So instead of a polygon following the edges of the pixels, it will instead be passing through the center of the connected pixels... This is to avoid having a scale effect of following the pixels edges. Jeff, With the current algorithm, this is not really possible. I am also not clear what it would mean to go from pixel center to pixel center. The algorithm attempts to identify the borders between regions of different pixel values and turn them into polygons. What does it mean to make a polygon boundary that goes through the center of a pixel with a particular value? Another algorithm you might want to keep in mind is the contour generator. It treats the the raster values as a continuous field, and builds edges based on linear interpolation between pixel centers. This gives a result that could pass through a pixel center if it happens to be an exact contour level. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Brian Case KF7WPK r...@winkey.org ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Multiple extensions in GDAL_DMD_EXTENSION ?
People *usually* want a list of extensions so they can automatically categorize the format of files on disk or to filter to only show extensions they think GDAL supports. I find this practice abhorrent! GDAL is based on the idea that file formats are discovered by inspecting file contents rather than based on extension and I don't want to make it too easy for applications to ignore this principle and revert to extensions. In this case, its about filtering files in a GUI. I agree that its probably a good idea to keep GDAL_DMD_EXTENSION as it is (preferred extension), and add GDAL_DMD_EXTENSION_LIST as alternative filtering options. And, of course documenting the intention of these, and the behaviour in GDAL's file probing. - Oyvind ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
