[postgis-devel] wktraster ST_ConvexHull

Paragon Corporation lr at pcorp.us
Tue Apr 6 21:21:30 PDT 2010


Pierre,

You may be sorry for asking us for our opinion :).

We had a discussion about this.  Our general feeling is first and foremost
avoid terminology that is commonly used to mean something else
and secondly avoid introducing new terminology.  Admittedly those are
somewhat subjective rules of thumb depending on which culture (both
technology and your preferred spoken language) you are coming from.

More specifically
Stick with terminology PostGIS people are used to to get PostGIS user
adoption.  
Use well-known raster terminology if no parallel in PostGIS to get raster
analysts on board and introduce PostGIS users to new industry concepts --
this part you need to help us with since we are not as familiar with the
standard lingo used in raster analysis.

This is where it would be really good to get other peoples opinions.  So
anybody feel free to chime in. Might even help to post to PostGIS users
group since we have a lot of raster analysts folks in that group.  Big soil
following I believe.

Now to the specifics.

> I suggested in february that we could rename ST_Shape to ST_Outline. But
got no further feedback. Should we?
We both hate ST_Shape for two reasons --
a) it introduces terminology used in other spatial databases to output to
EzRee shape format and like it or not, 
that's the first thing a lot of vector folks are going to think when they
see that name.
b) It just introduces another term in the mix that sounds like a
data/geometry type but isn't

ST_Outline is better than ST_Shape but it introduces a new term that sounds
more like a line than a polygon.

I liked the ST_Silouette name you came up with better, if only I could
actually spell that word. That does introduce new terminology, so Leo
crossed that one out.  Hmm maybe ST_Shadow() -- new terminology out the
door. 

We prefer just ST_AsPolygon or ST_Polygon for what you refer to as ST_Shape.
It returns a polygon period. 


> I never liked PostGIS ST_Dump.... Seems to me that ST_AsSimplePolygons()
or ST_SingleParts() would be 
> much more meaningful... We could add an "s" though to ST_AsPolygons().

What is wrong with ST_Dump* -- Admittedly the name isn't great, but when
PostGIS people think about ST_Dump* they think of the exploding family 
of functions that returns a geometry with some sort of path like info.  In
this case your path like info is the pixel value.  Not an array but a
numeric.  Still there is parallel meaning there.

So we prefer -  ST_DumpAsPolygon or something like that.  


The problem with AsSimplePolygons is you are returning a pixel band value
along with the polygon so its not really a polygon and you are returning a
collection of polygons.  The function name doesn't give you a clue about
that.  I suppose you could use the PostGIS 2.0 *Extract term

like ST_ExtractAsPolygons or something like that. 

---

SingleParts is too vague -- We can't tell if that's  a raster band or a
geometry or what its too generic.

>>The distinction I see  it would always return a dump of polygons rather 
>>than an arbitrary dump of geometries And the path value would be 
>> replaced with a pixel value.

> One problem I see is that people see the result of ST_Dump as simple
polygons when the result of 
> ST_AsPolygon is not necessarily simple polygons. You get simple polygons
only when you add the 
> 'CONTIGUOUS' keyword to the function (ST_AsPolygon(raster, integer,
'CONTIGUOUS')).

Really -- I always thought of ST_Dump as returning geometries since they
need not be polygons and the geometry_dump data type returns any geometry
under the sun with an acommpanying path element.  The other dump functions
don't even return polygons -- e.g. ST_DumpRings, ST_DumpPoints. 

 So to me it just dumps out the contents in some form down to its roots
whatever you define roots to mean (Dump, DumpPoints, DumpRings etc.)

Thanks,
Regina and Leo






More information about the postgis-devel mailing list