Re: [postgis-users] Problem with convex hulls that cross the dateline
Sarah,
I'm sure that there are good reasons not to do this, but could you translate
your points left or right, create your convex hull then translate the polygon
back...?
Otherwise you could project it onto a custom projection that covers your area
of interest? As an example look for an equal area proj string (I know there is
one for Australia GDA94 Albers - http://www.spatialreference.org/ref/epsg/3577)
and shift the lat and lon parameters...
cheers
Ben
On 07/09/2011, at 1:13 AM, Sarah Berke wrote:
> Hello,
>
> I'm having trouble making convex hulls that cross the international dateline.
> Imagine 4 points making a square with the international dateline running down
> the middle--I would like the convex hull to be that square, but instead I get
> a giant rectangle that goes across the entire planet. I've done some reading,
> and it sounds like GEOS generally has a hard time dealing with the
> dateline--is that accurate? Does anyone know of a way to get around this? I
> was thinking that it might work if I use an SRID that is just like 4326 but
> with a central meridian of 180, does that sound like a good plan? I'm pretty
> new to postGIS and I'm not sure how to either find such an SRID or how to
> define it--I've been trying to find an explanation of SRID syntax and so far
> coming up empty. If anyone has advice for solving this problem, or for places
> where I can learn more about defining custom SRIDs, I'd be really grateful!
>
> Here's an example--if you make this table and then look at it in QGIS (or
> whatever) along with a world map, you'll see a big rectangle spanning the
> entire map. On a map with central meridian of zero, I'd want to see half the
> polygon on the left side of the map and the other half on the right side.
>
> CREATE TABLE example AS
> SELECT ST_ConvexHull(
> ST_Collect(ST_GeomFromText('MULTIPOINT(175 5, 175 30, -175 5, -175 30)')
> ))::geography(Polygon, 4326) ;
>
>
> Thanks very much,
> Sarah
>
> _
> Sarah K Berke
> Postdoctoral Scholar
> Department of the Geophysical Sciences
> University of Chicago
> 5734 S. Ellis Ave
> Chicago, IL 60637
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Problem with convex hulls that cross the dateline
On Tue, Sep 6, 2011 at 10:18 PM, Paragon Corporation wrote: > Sarah, > > I'm having trouble making convex hulls that cross the international > dateline. Imagine 4 points making a square with the international dateline > running down the middle--I would like the convex hull to be that square, but > instead I get a giant rectangle that goes across the entire planet. I've > done some reading, and it sounds like GEOS generally has a hard time dealing > with the dateline--is that accurate? > Yes GEOS only deals with planar coordinates. Geography is the only > geodetic aware type and there is no ConvexHull function for it. Although you could hack one up easily enough by copying the ideas in ST_Buffer(geography) P ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Problem with convex hulls that cross the dateline
Sarah,
> I'm having trouble making convex hulls that cross the international
dateline. Imagine 4 points making a square with the international dateline
running down the middle--I would like the convex hull to be that square, but
instead I get a giant rectangle that goes across the entire planet. I've
done some reading, and it sounds like GEOS generally has a hard time dealing
with the dateline--is that accurate?
Yes GEOS only deals with planar coordinates. Geography is the only
geodetic aware type and there is no ConvexHull function for it.
> Does anyone know of a way to get around this? I was thinking that it
might work if I use an SRID that is just like 4326 but with a central
meridian of 180, does that sound like a good plan?
No. You should use a planar projection of some sort. 4326 squashed on a
map is no good. Paul Ramsey might have some thoughts on the matter.
> I'm pretty new to postGIS and I'm not sure how to either find such an
SRID or how to define it--I've been trying to find an explanation of SRID
syntax and so far coming up empty. If anyone has advice for solving this
problem, or for places where I can learn more about defining custom SRIDs,
I'd be really grateful!
You might want to check out http://spatialreference.org
> Here's an example--if you make this table and then look at it in QGIS
(or whatever) along with a world map, you'll see a big rectangle spanning
the entire map. On a map with
> central meridian of zero, I'd want to see half the polygon on the left
side of the map and the other half on the right side.
> CREATE TABLE example AS
> SELECT ST_ConvexHull(
> ST_Collect(ST_GeomFromText('MULTIPOINT(175 5, 175 30, -175 5, -175
30)') ))::geography(Polygon, 4326) ;
My guess is you'll have to cut your area into pieces. Still then its not
that pretty when you try to rejoin.
Sorry couldn't be more help,
Regina
http://www.postgis.us
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] klickstreet is looking for PostGIS expertise, thx!
Klickstreet, a Mountain View, CA based startup is developing game-changing location based apps. We seek a database designer/dba with expertise in PostGIS to work 10 - 15 hours per week in exchange for stock. Skills in Hadoop, Java, Clojure are a plus. Think you'll appreciate our team and what we are up to. http://www.klickstreet.com (stealth) Contact: Joseph Hentz, co-founder/ceo Thank you! ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] Problem with convex hulls that cross the dateline
Hello,
I'm having trouble making convex hulls that cross the international
dateline. Imagine 4 points making a square with the international dateline
running down the middle--I would like the convex hull to be that square, but
instead I get a giant rectangle that goes across the entire planet. I've
done some reading, and it sounds like GEOS generally has a hard time dealing
with the dateline--is that accurate? Does anyone know of a way to get around
this? I was thinking that it might work if I use an SRID that is just like
4326 but with a central meridian of 180, does that sound like a good plan?
I'm pretty new to postGIS and I'm not sure how to either find such an SRID
or how to define it--I've been trying to find an explanation of SRID syntax
and so far coming up empty. If anyone has advice for solving this problem,
or for places where I can learn more about defining custom SRIDs, I'd be
really grateful!
Here's an example--if you make this table and then look at it in QGIS (or
whatever) along with a world map, you'll see a big rectangle spanning the
entire map. On a map with central meridian of zero, I'd want to see half the
polygon on the left side of the map and the other half on the right side.
CREATE TABLE example AS
SELECT ST_ConvexHull(
ST_Collect(ST_GeomFromText('MULTIPOINT(175 5, 175 30, -175 5, -175 30)')
))::geography(Polygon, 4326) ;
Thanks very much,
Sarah
_
Sarah K Berke
Postdoctoral Scholar
Department of the Geophysical Sciences
University of Chicago
5734 S. Ellis Ave
Chicago, IL 60637
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] OT: Question on performance in plpgsql function
Stephen, this is just a wild guess and going from memory to boot... I believe there can be an issue with pgsql where the reader and writer processes interfere with each other and the writer "stalls". There are ways to detect this if it is happening and configuration parameters to set that are meant to help. It seems to me we have run across this in our shop when we have update processes running through an entire long (and maybe wide) table. Perhaps this is at the root of your problem. On Sep 6, 2011 6:39 AM, "Stephen Woodbridge" wrote: > On 9/5/2011 11:26 PM, Stephen Woodbridge wrote: >> Hi all, >> >> This may be a little off topic, but there are a lot of smart minds here >> that might know. >> >> I have a plpgsql function the does some work to compute all the >> intersections with street names in a road network. It creates a vertex >> table like in pgrouting and an intersection table. Then populates the >> tables from a streets network and finally updates the intersection table >> based on the number of connected segments that have names. >> >> The performance issue I'm having is that if I include the final update >> in the procedure is takes forever (well longer than 12 hours when I >> aborted it) and postgres runs at 100 CPU for all that time. But if I >> comment out the update and run the procedure it takes say 1 hour to run, >> and then I then run the update from the command line it takes say >> another hour to run that, so a total of 2 hours. > > OK, so here are some real numbers as i just aborted it after 48000 sec > and rerunning part one without the update took 460 sec. and then running > the update alone took 75 sec. So aborted at about 13 hrs vs completing > in two steps in 9 minutes. > > And after reading the docs some more I can not do a commit in any stored > procedure, I guess I will have to wrap the two commands into a > client-side script, unless anyone has any other ideas on why this is > happening. > > -Steve > >> plpgsql function run in a single transaction and breaking it into two >> steps does it in two transaction, so I figure that has something to do >> with it. An you can not COMMIT in a plpgsql function. >> >> Any thoughts on how to fix this? >> Can a SQL procedure do a COMMIT? If so I might be able to reorg the >> process into two some plpgsql procedures that get called from a SQL >> procedure. >> >> Thoughts? >> >> -Steve >> ___ >> postgis-users mailing list >> postgis-users@postgis.refractions.net >> http://postgis.refractions.net/mailman/listinfo/postgis-users > > ___ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] compile on solaris 11 sparc
On 6 September 2011 10:19, Mark Cave-Ayland wrote: > > Well just for the record - the issue here was that the person who built your > PostgreSQL binaries used the native Sun compiler on their system hence > embedding this as the default CC in the PGXS Makefile used by PostGIS. If > you still wanted to use Solaris then using GCC to build both PostgreSQL and > PostGIS on your server should give you something that would work. > > > HTH, > > Mark. > Thanks Mark. I'll keep that in mind as I'm sure Solaris will seduce me again in the future. It always does! ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] OT: Question on performance in plpgsql function
On 9/5/2011 11:26 PM, Stephen Woodbridge wrote: Hi all, This may be a little off topic, but there are a lot of smart minds here that might know. I have a plpgsql function the does some work to compute all the intersections with street names in a road network. It creates a vertex table like in pgrouting and an intersection table. Then populates the tables from a streets network and finally updates the intersection table based on the number of connected segments that have names. The performance issue I'm having is that if I include the final update in the procedure is takes forever (well longer than 12 hours when I aborted it) and postgres runs at 100 CPU for all that time. But if I comment out the update and run the procedure it takes say 1 hour to run, and then I then run the update from the command line it takes say another hour to run that, so a total of 2 hours. OK, so here are some real numbers as i just aborted it after 48000 sec and rerunning part one without the update took 460 sec. and then running the update alone took 75 sec. So aborted at about 13 hrs vs completing in two steps in 9 minutes. And after reading the docs some more I can not do a commit in any stored procedure, I guess I will have to wrap the two commands into a client-side script, unless anyone has any other ideas on why this is happening. -Steve plpgsql function run in a single transaction and breaking it into two steps does it in two transaction, so I figure that has something to do with it. An you can not COMMIT in a plpgsql function. Any thoughts on how to fix this? Can a SQL procedure do a COMMIT? If so I might be able to reorg the process into two some plpgsql procedures that get called from a SQL procedure. Thoughts? -Steve ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] compile on solaris 11 sparc
On 06/09/11 12:54, Doug McComber wrote: Didn't work (E flag). I ended up dumping Solaris for FreeBSD. You see I always fall for this trap. Every time I dust of my Sunfire I get enchanted with the idea of using Solaris. But, and especially with Oracle now, Solaris is not very free or open. And I always end up running into some hurdle that isn't worth struggling with when there are plenty of good alternatives (Debian and FreeBSD come to mind). Of course I am ranting here so I'll stop. :) Thanks for your and everyone else's help in trying to solve this. Doug Well just for the record - the issue here was that the person who built your PostgreSQL binaries used the native Sun compiler on their system hence embedding this as the default CC in the PGXS Makefile used by PostGIS. If you still wanted to use Solaris then using GCC to build both PostgreSQL and PostGIS on your server should give you something that would work. HTH, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] compile on solaris 11 sparc
On 2 September 2011 21:28, Martin Spott wrote: > Doug McComber wrote: >> On 09/ 2/11 04:59 AM, Martin Spott wrote: > >>> CC="gcc -m64" >>> CXX="g++ -m64" >>> CPP="gcc -m64 -E" > [...] >> CPP="gcc" > [...] >> /opt/studio11/SUNWspro/bin/cc -Xa -E -traditional-cpp postgis.sql.in.c | >> grep -v '^#' > postgis.sql.in >> /bin/sh: line 1: /opt/studio11/SUNWspro/bin/cc: not found > > Here's the difference. In order to call GCC as the preprocessor, you should > add "-E", otherwise configure will (at least I'd expect it this way) realize > this is not a working CPP and will look for an alternate - which typically > is 'cc' on Solaris. > > Cheers, > Martin. Didn't work (E flag). I ended up dumping Solaris for FreeBSD. You see I always fall for this trap. Every time I dust of my Sunfire I get enchanted with the idea of using Solaris. But, and especially with Oracle now, Solaris is not very free or open. And I always end up running into some hurdle that isn't worth struggling with when there are plenty of good alternatives (Debian and FreeBSD come to mind). Of course I am ranting here so I'll stop. :) Thanks for your and everyone else's help in trying to solve this. Doug ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
