[postgis-devel] wktraster ST_ConvexHull

[Pierre Racine]

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

I don't like opinions but I like (good) arguments :-) Unserstand that I just defend myself from quick suggestions/preferences. Otherwise we would spend all our time on that. I listen to you.

>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.

I like those rules. Even if they are subject to interpretation, they provide us with a good base.

>> 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.

Ok. Adopted. St_Shape() will be ST_Polygon().


>> 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.

Well its easy to say that "now" people think about it this way. They are just used to this "stange" terminology. It could dump the coordinate values, we have no clue. AsSimplePolygons or AsSimpleGeometries would be more explicit.

> In this case your path like info is the pixel value.  Not an array but a
>numeric.  Still there is parallel meaning there.

I agree that there is a strong parallel in behavior between ST_Dump* and our AsPolygon(s) and this is certainly the main argument. We will name ST_AsPolygon() ST_DumpAsPolygons() instead. With a "s" or no? I like the s. It means "expect many of them".

>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.

Misunderstanding: I was speaking about AsSimplePolygons() and ST_SingleParts() as a better name for PostGIS ST_Dump(), not for our ST_AsPolygon(). I agree that it would not make much sence. SingleParts is ArcGIS terminology.

Pierre