[postgis-users] PostGIS 2.0 Wishlist

ValiSystem vali.system at free.fr
Wed May 9 08:15:40 PDT 2007


On 9 mai 07, at 15:04, Frank Warmerdam wrote:

> Nicolas Ribot wrote:
>>> Likewise here -- we have some work-arounds, but that's exactly  
>>> what they
>>> are. Dateline issues mainly -- but I know I've seen issues with  
>>> polar
>>> regions as well. OTH our engineers haven't conjured up  
>>> suggestions for
>>> functions that haven't already been made, and none of those seem  
>>> to be a
>>> high priority. (Is there geld for this work is another  
>>> question ... our
>>> new corporate owners have more need for dateline / polar areas  
>>> than did
>>> our core business at GlobeXplorer, which was more US/Euro-centric  
>>> (but
>>> there are US possessions and parts of Alaska that do cross the  
>>> dateline)
>>> but I also have no idea if they are open to funding OS. I can  
>>> always ask
>>> I guess, if there's enough other interest.
>>>
>> French Space Agency (CNES) is also very interested by adding
>> geocentric support into PostGIS.
>> We (camptocamp) are in touch with them to fund a survey to estimate
>> the amount of work needed to do so.
>> We will keep the list posted about this project.
>> Nicolas Ribot - CampToCamp.
>
> Nicolas,
>
> I believe PROJ.4 already supports geocentric coordinate systems, so in
> theory it should be as simple as adding a new entry in the  
> spatial_ref_sys
> table associating an SRS ID with the PROJ.4 definition.
>
> eg (at proj.4 commandline):
>
> cs2cs +proj=latlong +datum=WGS84 +to +proj=geocent
> -117 33
> -2430880.68     -4770871.97 3453958.64
>
> Best regards,
> -- 
> --------------------------------------- 
> +--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,  
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | President OSGeo, http:// 
> osgeo.org
>
>

Nicolas already mailed last week about geocentric support, and i  
think he wants the whole postgis to support geodetic coordinates, not  
only a geodetic projection system. That means, actually, a support of  
geometric operations on a ellipsoid, not a plan, (as it is done today  
AFAIK). For example, on a plan, two geometries placed at a -180 + 180  
are far, on the ellipsoid, they are near. (another example with  two  
objects  the same latitude latitudes, with a fixed longitude, they  
are farther at low (near 0) latitudes and nearer at extreme  
latitudes, but in a plan, distance is constant).

(as nicolas said last week, Oracle spatial implements that)

Today, operations are done by geos, and i didn't found anything that  
shows the possibility to to do geometric operation in another space  
than a plan. If i'm wrong then it's a good news, because full  
geodetic support could be added very quickly (just have to specify  
type of space to geos), but i don't think it is the case, since  
performing operations on a ellipsoid is slower and more complex  
(depending on implementation, the algos are more complex, or the  
mathematical model is more complex, or both).

I'd be happy to see that one day, GIS world is evolving very fast  
these days, and virtual globes may make people need that kind of  
features much more than with the classical 2D, projection based,  
viewer (even if continuous horizontal scrolling is not uncommon).

But i would not be surprise that creating another implementation of  
basic geos algorithms would make it possible, it would be interesting  
to know how complex it would be, and if it could make all the others  
geos function work auto-magically (having to fix the whole geos code  
would be sad, long and painfull).

This is for the geometric operations. There is also a problem with  
the RTree BBoxes, since the RTree relies on distance, and distance  
depends of calculation formulas, for the same data, a geodetic RTree  
would not be the same as the  RTrees we currently use. Since it could  
not be simple as greater than a lower than operations on BBoxes  
corners, i don't know what would be the actual runtime cost, but i'm  
not optimistic.

But i'm not an expert, i'm just curious to see what kind of problems  
it raises. This is a great feature and i'd like to see it, but i  
would not ask for something that implies too much work.

Best Regards





More information about the postgis-users mailing list