Re: [postgis-users] Nearest neighbor in 3D
Using ST_3DDistance will work and give you the right answer, but it will not be index assisted. The KNN operator <-> is only implemented against the 2D index currently. Paul On Fri, May 25, 2012 at 5:15 PM, Bartosz Bekier wrote: > Hello All! > > This is my first post on the PostGIS mailing list:-). > > I would like to use the <-> to solve the nearest neighbor problem, but in 3D > space. I tried to do this in 2D and it works perfectly, but apparently it > doesn't cover the 3D case. > > Basically I have a table of 3D points (x, y, z) and would like to do: > > ORDER BY point <-> POINT(0 0 0) > > but the distance taken into account should be 3D Euclidean distance. Do I > have to use ST_3DDistance() for it or is there a faster way? > > Thanks in advance! > > Regards, > -- > Bartosz Bekier > > > ___ > 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] loading mostly identical states-based shapefiles
I have US states shape files that are mostly identical, except for those silly legacy columns that have the state code prefix. Is there a way I can import these shapefiles via `shp2pgsql` specifying to *not* load a particular column? As is, the loader croaks because the '-c' switch creates the table on the first state load creating a column starting with that state's code, and then the second state can't find that column. An additional question -- the '-S' switch promises to "Generate simple geometries instead of MULTI geometries." Why would I want to do that? Please educate me. -- Puneet Kishor ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] How to smoothify (rounding the edges)?
Dear list, I am trying smoothify some linestring. ST_OffsetCurve looks good, but simply simulates just one side of a ST_Buffer. Chaining of ST_OffsetCurve could be the right way. SELECT ST_OffsetCurve( ST_OffsetCurve( ST_OffsetCurve( ST_GeometryFromText( 'LINESTRING( 369172.556 5645414.822 ,369083.213632107 5645360.17950829 ,369074.985 5645382.472 ,368991.798 5645340.312 ,368948.814 5645362.793 ,368922.301 5645286.628 ,368868.668 5645301.318 ,368762.112 5645217.804 ,368722.516936163 5645220.71672624 ,368734.299541879 5645251.65724707 ,368696.988917574 5645268.59693863 ,368652.612373605 5645243.03860572 ,368655.33980816 5645277.83126126 ,368622.411 5645234.496)' ,25832) ,-5 ,'quad_segs=4 join=round') ,10 ,'quad_segs=4 join=round') ,-5 ,'quad_segs=4 join=round'); http://postgis.17.n6.nabble.com/file/n4997829/smoothify.png How can I get my data edgeless. Thanks a lot and best regards, Daniel -- View this message in context: http://postgis.17.n6.nabble.com/How-to-smoothify-rounding-the-edges-tp4997829.html Sent from the PostGIS - User mailing list archive at Nabble.com. ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Topology: Simplifying Coastlines with Islands
On Fri, May 25, 2012 at 11:15:09PM +0200, Michiel J. van Heek wrote:
> These are the warnings for edge 11652, the coastline of Norway (on
> the screenshot in my previous post):
>
> WARNING: Simplification of edge 11652 with tolerance 0.5 failed:
> SQL/MM Spatial exception - geometry crosses an edge
> WARNING: Simplification of edge 11652 with tolerance 0.25 failed:
> SQL/MM Spatial exception - curve not simple
...
>
> The "curve not simple" makes we want to try your suggestion to use
> ST_SimplifyPreserveTopology instead of ST_Simplify. I will try that
> tomorrow (it is late in my timezone) and let you know the outcome.
Yeah, it might work at 0.25 :)
> The ticket you mentioned seems to be about creating topology from
> geometry. That part - SELECT CreateTopology('countries_topology',
> 4326) - ran flawless in my case. (Long, but without errors.) The
> ticket is not about simplifying topology, or is it?
I considered it generally about error messages. The first one above,
for example, might be more useful if it told you _which_ edge was
the simplified edge crossing, and maybe even _where_...
--strk;
,--o-.
| __/ |Delivering high quality PostGIS 2.0 !
| / 2.0 |http://strk.keybit.net - http://vizzuality.com
`-o--'
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Topology: Simplifying Coastlines with Islands
Hello Sandro,
Thank you for your reply.
These are the warnings for edge 11652, the coastline of Norway (on the
screenshot in my previous post):
WARNING: Simplification of edge 11652 with tolerance 0.5 failed:
SQL/MM Spatial exception - geometry crosses an edge
WARNING: Simplification of edge 11652 with tolerance 0.25 failed:
SQL/MM Spatial exception - curve not simple
WARNING: Simplification of edge 11652 with tolerance 0.125 failed:
SQL/MM Spatial exception - curve not simple
WARNING: Simplification of edge 11652 with tolerance 0.0625 failed:
SQL/MM Spatial exception - curve not simple
WARNING: Simplification of edge 11652 with tolerance 0.03125 failed:
SQL/MM Spatial exception - curve not simple
WARNING: Simplification of edge 11652 with tolerance 0.015625 failed:
SQL/MM Spatial exception - curve not simple
WARNING: Simplification of edge 11652 with tolerance 0.0078125
failed: SQL/MM Spatial exception - curve not simple
The "curve not simple" makes we want to try your suggestion to use
ST_SimplifyPreserveTopology instead of ST_Simplify. I will try that
tomorrow (it is late in my timezone) and let you know the outcome.
The ticket you mentioned seems to be about creating topology from
geometry. That part - SELECT CreateTopology('countries_topology',
4326) - ran flawless in my case. (Long, but without errors.) The
ticket is not about simplifying topology, or is it?
Best,
Michiel.
Quoting Sandro Santilli :
On Fri, May 25, 2012 at 06:36:39PM +0200, Michiel J. van Heek wrote:
Dear list,
I am trying to simplify a dataset of country boundaries by using
topology functions, as described in Strk's Blog:
http://strk.keybit.net/blog/2012/04/13/simplifying-a-map-layer-using-postgis-topology/
This has worked quite well, except for coastlines with islands
nearby. The simplified coastline would probably intersect the
island, or pass the island at the wrong side, leading to invalid
topology. Does that mean that countries with coastal islands such as
Canada and Norway (see attached image) cannot be simplified this
way?
I think you should figure out more about why the simplification
fails. The function in the post raises a WARNING on each failure,
what does that warning say ? I'm asking because there's also the
case of self-topology breakage, which could be prevented by using
ST_SimplifyPreserveTopology rather than ST_Simplify.
If your assumption about why simplification fails is correct you
could make things better by splitting the complex edge near the
islands (see ST_ModEdgeSplit).
Ideally, islands in the way of a to-be-simplified coastline should
be merged with the mainland. (I have already removed the smaller
islands, but I think I should not remove the bigger islands too.)
The function in the post is still only considering each edge in
turn and has no knowledge of which faces are defined by those
edges, let alone which faces define your feature (mainland, island).
You'll need something more sofisticated for that, and I'm not sure
there's an easy general handling for such cases. I mean, there could
still be the case in which simplifying an edge would intersect an
island which doesn't belong to the same feature...
Let me know what you found when looking closer at the failure messages.
There's a ticket to make those messages more useful to understand
the problem [1], if you hit that please add to that ticket, and maybe
provide also a patch :)
[1] http://trac.osgeo.org/postgis/ticket/1817
Finally: make sure to run the latest and greatest postgis & GEOS.
There have been a few fixes and improvements lately.
--strk;
,--o-.
| __/ |Delivering high quality PostGIS 2.0 !
| / 2.0 |http://strk.keybit.net - http://vizzuality.com
`-o--'
___
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] Topology: Simplifying Coastlines with Islands
On Fri, May 25, 2012 at 06:36:39PM +0200, Michiel J. van Heek wrote: > Dear list, > > I am trying to simplify a dataset of country boundaries by using > topology functions, as described in Strk's Blog: > http://strk.keybit.net/blog/2012/04/13/simplifying-a-map-layer-using-postgis-topology/ > > This has worked quite well, except for coastlines with islands > nearby. The simplified coastline would probably intersect the > island, or pass the island at the wrong side, leading to invalid > topology. Does that mean that countries with coastal islands such as > Canada and Norway (see attached image) cannot be simplified this > way? I think you should figure out more about why the simplification fails. The function in the post raises a WARNING on each failure, what does that warning say ? I'm asking because there's also the case of self-topology breakage, which could be prevented by using ST_SimplifyPreserveTopology rather than ST_Simplify. If your assumption about why simplification fails is correct you could make things better by splitting the complex edge near the islands (see ST_ModEdgeSplit). > Ideally, islands in the way of a to-be-simplified coastline should > be merged with the mainland. (I have already removed the smaller > islands, but I think I should not remove the bigger islands too.) The function in the post is still only considering each edge in turn and has no knowledge of which faces are defined by those edges, let alone which faces define your feature (mainland, island). You'll need something more sofisticated for that, and I'm not sure there's an easy general handling for such cases. I mean, there could still be the case in which simplifying an edge would intersect an island which doesn't belong to the same feature... Let me know what you found when looking closer at the failure messages. There's a ticket to make those messages more useful to understand the problem [1], if you hit that please add to that ticket, and maybe provide also a patch :) [1] http://trac.osgeo.org/postgis/ticket/1817 Finally: make sure to run the latest and greatest postgis & GEOS. There have been a few fixes and improvements lately. --strk; ,--o-. | __/ |Delivering high quality PostGIS 2.0 ! | / 2.0 |http://strk.keybit.net - http://vizzuality.com `-o--' ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Nearest neighbor in 3D
Using ST_3DDistance will work and give you the right answer, but it will not be index assisted. The KNN operator <-> is only implemented against the 2D index currently. Paul On Fri, May 25, 2012 at 5:15 PM, Bartosz Bekier wrote: > Hello All! > > This is my first post on the PostGIS mailing list:-). > > I would like to use the <-> to solve the nearest neighbor problem, but in 3D > space. I tried to do this in 2D and it works perfectly, but apparently it > doesn't cover the 3D case. > > Basically I have a table of 3D points (x, y, z) and would like to do: > > ORDER BY point <-> POINT(0 0 0) > > but the distance taken into account should be 3D Euclidean distance. Do I > have to use ST_3DDistance() for it or is there a faster way? > > Thanks in advance! > > Regards, > -- > Bartosz Bekier > > > ___ > 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] ST_Aspect artifacts?
Hi, May be you can use gdal_dem with PostGis Raster reader (mode 2) if you want create derived product from DEM? http://www.gdal.org/gdaldem.html It is working very well with gdal 1.8. Moreover you can extrapolate values along the borders of the tiles. If you just want merging adjacent rasters you can use gdal_translate with PostGis Raster reader (mode 2). David > Date: Fri, 25 May 2012 19:08:23 +0200 > From: cavall...@faunalia.it > To: postgis-users@postgis.refractions.net > Subject: Re: [postgis-users] ST_Aspect artifacts? > > Il 25/05/2012 19:02, Pierre Racine ha scritto: > > Yeah. ST_Union is good for unioning overlapping rasters (e.g. computing the > > mean of a temperature series) but not for merging adjacent rasters. We will > > have to write something else for that. > > > ok. again, thanks for clarifying. > all the best. > > -- > Paolo Cavallini > See: http://www.faunalia.it/pc > > ___ > 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] Error browsing database
Il 25/05/2012 18:39, Bborie Park ha scritto: > On 05/25/2012 08:57 AM, Paolo Cavallini wrote: >> you better believe it ;) >> Faunalia (Giuseppe Sucameli) is the maintainer of it. >> All the best. >> > Really?! I'll have to try that out. > sure you should. comments, tickets, fixes and improvements welcome: http://hub.qgis.org/projects/dbmanager/ all the best. -- Paolo Cavallini See: http://www.faunalia.it/pc ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] ST_Aspect artifacts?
Il 25/05/2012 19:02, Pierre Racine ha scritto: > Yeah. ST_Union is good for unioning overlapping rasters (e.g. computing the > mean of a temperature series) but not for merging adjacent rasters. We will > have to write something else for that. > ok. again, thanks for clarifying. all the best. -- Paolo Cavallini See: http://www.faunalia.it/pc ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] ST_Aspect artifacts?
Yeah. ST_Union is good for unioning overlapping rasters (e.g. computing the mean of a temperature series) but not for merging adjacent rasters. We will have to write something else for that. Pierre > -Original Message- > From: postgis-users-boun...@postgis.refractions.net [mailto:postgis-users- > boun...@postgis.refractions.net] On Behalf Of Paolo Cavallini > Sent: Friday, May 25, 2012 12:53 PM > To: postgis-users@postgis.refractions.net > Subject: Re: [postgis-users] ST_Aspect artifacts? > > Il 25/05/2012 18:29, Pierre Racine ha scritto: > > Not yet... > I imagined, thanks. So I tried to merge the rasters with ST_Union, but I > had to stop after ~2h with pg@100% CPU (a small raster, 1300 tiles 64x64). > Urgh! > All the best. > > -- > Paolo Cavallini > See: http://www.faunalia.it/pc > > ___ > 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] ST_Aspect artifacts?
Il 25/05/2012 18:29, Pierre Racine ha scritto: > Not yet... I imagined, thanks. So I tried to merge the rasters with ST_Union, but I had to stop after ~2h with pg@100% CPU (a small raster, 1300 tiles 64x64). Urgh! All the best. -- Paolo Cavallini See: http://www.faunalia.it/pc ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Error browsing database
On 05/25/2012 08:57 AM, Paolo Cavallini wrote: > Il 25/05/2012 17:32, Bborie Park ha scritto: >> I don't believe the DB Manager in QGIS works for PostGIS Raster. > you better believe it ;) > Faunalia (Giuseppe Sucameli) is the maintainer of it. > All the best. > Really?! I'll have to try that out. -- Bborie Park Programmer Center for Vectorborne Diseases UC Davis 530-752-8380 bkp...@ucdavis.edu ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] ST_Aspect artifacts?
Not yet... > -Original Message- > From: postgis-users-boun...@postgis.refractions.net [mailto:postgis-users- > boun...@postgis.refractions.net] On Behalf Of Paolo Cavallini > Sent: Friday, May 25, 2012 8:57 AM > To: PostGIS Users Discussion > Subject: [postgis-users] ST_Aspect artifacts? > > Hi all. > The raster resulting from: > CREATE TABLE aspect as select rid, ST_aspect(rast,1,'8BUI') as rast from > hdr; > does not calculate correctly values along the borders of the tiles. > Any way to avoid this? > All the best. > > -- > Paolo Cavallini > See: http://www.faunalia.it/pc > > ___ > 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] Error browsing database
Il 25/05/2012 17:32, Bborie Park ha scritto: > I don't believe the DB Manager in QGIS works for PostGIS Raster. you better believe it ;) Faunalia (Giuseppe Sucameli) is the maintainer of it. All the best. -- Paolo Cavallini See: http://www.faunalia.it/pc ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Error browsing database
On Fri, May 25, 2012 at 3:24 AM, Paolo Cavallini wrote: > Il 25/05/2012 11:22, Paolo Cavallini ha scritto: >> So, for the record, there were 2 different issues: - id and column >> naming (rid, rast) - irregular blocks. Thanks for help in clarifying. > > next step: loading the raster in QGIS (DB Manager, drag&drop) hangs PG: > 8 postgres 20 0 403m 123m 115m R 98,8 6,2 62:57.97 > postgres > for hours. Too bad, I had to restart PostgreSQL. > I think it is a problem in GDAL. > All the best. > > -- > Paolo Cavallini > See: http://www.faunalia.it/pc > I don't believe the DB Manager in QGIS works for PostGIS Raster. There is a PostGIS Raster plugin available though. I think it is available in the plugin manager... -bborie -- Bborie Park Programmer Center for Vectorborne Diseases UC Davis 530-752-8380 bkp...@ucdavis.edu ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] Nearest neighbor in 3D
Hello All! This is my first post on the PostGIS mailing list:-). I would like to use the <-> to solve the nearest neighbor problem, but in 3D space. I tried to do this in 2D and it works perfectly, but apparently it doesn't cover the 3D case. Basically I have a table of 3D points (x, y, z) and would like to do: ORDER BY point <-> POINT(0 0 0) but the distance taken into account should be 3D Euclidean distance. Do I have to use ST_3DDistance() for it or is there a faster way? Thanks in advance! Regards, -- Bartosz Bekier ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] ST_Aspect artifacts?
Hi all. The raster resulting from: CREATE TABLE aspect as select rid, ST_aspect(rast,1,'8BUI') as rast from hdr; does not calculate correctly values along the borders of the tiles. Any way to avoid this? All the best. -- Paolo Cavallini See: http://www.faunalia.it/pc ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Difference between ST_Union and ST_Collect
On 05/25/2012 08:41 PM, Sandro Santilli wrote: On Fri, May 25, 2012 at 08:38:44PM +1000, Luca Morandini wrote: The issue has been solved by using ST_Union, but I still can't fathom why entire polygons were dropped by ST_BuildArea when their boundaries intersected.. ST_BuildArea expects input to be correctly noded. Failing that, the actual result is undefined. Passing the input trough ST_Union is a trick to obtain proper noding. Crystal clear :) Regards, Luca Morandini Data Architect - AURIN project Department of Computing and Information Systems University of Melbourne ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Difference between ST_Union and ST_Collect
On Fri, May 25, 2012 at 08:38:44PM +1000, Luca Morandini wrote: > The issue has been solved by using ST_Union, but I still can't > fathom why entire polygons were dropped by ST_BuildArea when their > boundaries intersected.. ST_BuildArea expects input to be correctly noded. Failing that, the actual result is undefined. Passing the input trough ST_Union is a trick to obtain proper noding. --strk; ,--o-. | __/ |Delivering high quality PostGIS 2.0 ! | / 2.0 |http://strk.keybit.net - http://vizzuality.com `-o--' ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Difference between ST_Union and ST_Collect
On 05/25/2012 08:30 PM, Sandro Santilli wrote: On Fri, May 25, 2012 at 08:21:25PM +1000, Luca Morandini wrote: On 05/25/2012 07:26 PM, Sandro Santilli wrote: On Fri, May 25, 2012 at 01:52:45PM +1000, Luca Morandini wrote: after seeing some polygons disappear during the generalization process, I found out that ST_Union and ST_Collect are different beasts when dealing with intersecting lines. Yes, ST_Collect simply puts things togheter. ST_Union computes the point set union. Isn't the manual page clear about that ? That is clear, what I did not suspect was the different behaviour when there are "loops" in the collection of lines given as argument... well, it may be ST_BuildArea that has a different behaviour when the argument is a collection of linestrings or a single geometry. BuildArea is not an aggregate so won't "internally" collect the inputs. Of course, but it has a different behaviour when it is given a collection of lines (some intersecting) or a single geometry... on the other hand, it may be ST_Union that resolves the "loops" before sending the geometry to ST_BuildArea). I'm not sure this solves your problem. The issue has been solved by using ST_Union, but I still can't fathom why entire polygons were dropped by ST_BuildArea when their boundaries intersected.. Regards, Luca Morandini Data Architect - AURIN project Department of Computing and Information Systems University of Melbourne ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Difference between ST_Union and ST_Collect
On Fri, May 25, 2012 at 08:21:25PM +1000, Luca Morandini wrote: > On 05/25/2012 07:26 PM, Sandro Santilli wrote: > >On Fri, May 25, 2012 at 01:52:45PM +1000, Luca Morandini wrote: > > > >>after seeing some polygons disappear during the generalization > >>process, I found out that ST_Union and ST_Collect are different > >>beasts when dealing with intersecting lines. > > > >Yes, ST_Collect simply puts things togheter. ST_Union computes the > >point set union. Isn't the manual page clear about that ? > > That is clear, what I did not suspect was the different behaviour > when there are "loops" in the collection of lines given as > argument... well, it may be ST_BuildArea that has a different > behaviour when the argument is a collection of linestrings or a > single geometry. BuildArea is not an aggregate so won't "internally" collect the inputs. I'm not sure this solves your problem. --strk; ,--o-. | __/ |Delivering high quality PostGIS 2.0 ! | / 2.0 |http://strk.keybit.net - http://vizzuality.com `-o--' ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Error browsing database
Il 25/05/2012 11:22, Paolo Cavallini ha scritto: > So, for the record, there were 2 different issues: - id and column > naming (rid, rast) - irregular blocks. Thanks for help in clarifying. next step: loading the raster in QGIS (DB Manager, drag&drop) hangs PG: 8 postgres 20 0 403m 123m 115m R 98,8 6,2 62:57.97 postgres for hours. Too bad, I had to restart PostgreSQL. I think it is a problem in GDAL. All the best. -- Paolo Cavallini See: http://www.faunalia.it/pc ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Difference between ST_Union and ST_Collect
On 05/25/2012 07:26 PM, Sandro Santilli wrote: On Fri, May 25, 2012 at 01:52:45PM +1000, Luca Morandini wrote: after seeing some polygons disappear during the generalization process, I found out that ST_Union and ST_Collect are different beasts when dealing with intersecting lines. Yes, ST_Collect simply puts things togheter. ST_Union computes the point set union. Isn't the manual page clear about that ? That is clear, what I did not suspect was the different behaviour when there are "loops" in the collection of lines given as argument... well, it may be ST_BuildArea that has a different behaviour when the argument is a collection of linestrings or a single geometry. Regards, Luca Morandini Data Architect - AURIN project Department of Computing and Information Systems University of Melbourne ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Difference between ST_Union and ST_Collect
On Fri, May 25, 2012 at 01:52:45PM +1000, Luca Morandini wrote: > after seeing some polygons disappear during the generalization > process, I found out that ST_Union and ST_Collect are different > beasts when dealing with intersecting lines. Yes, ST_Collect simply puts things togheter. ST_Union computes the point set union. Isn't the manual page clear about that ? > P.S. > Sandro, I did not forget to help speeding up the topology > construction routines, it is just that next week we have a deadline, > hence I gave a lower priority to the task of setting up a machine > with the configuration you requested... stay tuned. I am ! --strk; ,--o-. | __/ |Delivering high quality PostGIS 2.0 ! | / 2.0 |http://strk.keybit.net - http://vizzuality.com `-o--' ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Error browsing database
Il 24/05/2012 22:22, Bborie Park ha scritto: > Correct. That and when each tile is transformed, the output isn't > aligned with the rest of the transformed tiles. There has been > discussion about adding a reference raster to ensure the transformed > tiles are aligned. So, for the record, there were 2 different issues: - id and column naming (rid, rast) - irregular blocks. Thanks for help in clarifying. -- Paolo Cavallini See: http://www.faunalia.it/pc ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
