[postgis-users] Problem (bug?) in ST_POLYGONIZE

Kevin Neufeld kneufeld at refractions.net
Tue Jan 15 09:02:45 PST 2008


No. ST_AsText() has it places, but as you've seen, it does not give you 
an accurate representation of your geometries.  It is for this reason 
that PostGIS moved away from the textual representation of geometries to 
binary way back in release 1.0.0.  Prior to this release, pg_dump would 
dump a database using the textual form and was prone to coordinate 
shifting and precision loss. There's more info on this canonical form if 
you search the postgis-users and postgis-devel archives.

Recommendation: use ST_AsEWKB(), or ST_AsBinary(), or ST_AsHEXEWKB() if 
you ever plan on editing your geometries - ie through JDBC.  
Alternatively, you could use ST_AsText(), but it would be a good idea to 
couple it closely with ST_Snaptogrid() (ie. by calling it after every 
geometry edit, or by placing a rule or trigger on your tables).

Cheers,
Kevin

Andreas Neumann wrote:
> Indeed - this ST_SnapToGrid() does the trick - and explains why
> ST_Polygonize failed. I wonder if there is a way to see these very slight
> inaccuracies with "ST_AsText()". In my case ST_AsText() only returned
> three digits after the comma (that's why I assumed the start/end points
> are actually the same), not the 10 digits you mention below. Is there any
> trick to tell ST_AsText() to be more accurate?
>
> Thanks again,
> Andreas
>
>   
>> This is not a bug. It looks like your linestrings are not properly noded.
>>
>> IE. on your line in question, the end node is POINT (697787.741
>> 247263.451), but the other two lines are noded at POINT
>> (697787.7410000002 247263.451).
>>
>> Try using snaptogrid().
>>
>> SELECT geom AS the_geom
>> FROM ST_Dump((
>>    SELECT ST_Polygonize(ST_SnapToGrid(the_geom, 0.001)) AS geom
>>    FROM admin.plz));
>>
>> Cheers,
>>
>> -------------
>> Kevin Neufeld
>> Software Developer
>> Refractions Research Inc.
>> 300-1207 Douglas St.
>> Victoria, B.C., V8W 2E7
>>
>> Phone: (250) 383-3022
>> Email: kneufeld at refractions.net
>>
>>
>>
>> Andreas Neumann wrote:
>>     
>>> Hello,
>>>
>>> I have a linenetwork with 15 LINESTRING() elements. I am using
>>> ST_POLYGONIZE() to create new POLYGON() elements. I'd expect to get 6
>>> polygons, but ST_POLYGONIZE() creates only 5 polygons. To make sure that
>>> my data is ok, I selected all start and endpoints of the LINESTRING()s
>>> and
>>> made sure that every start/endpoint of a LINESTRING() has two
>>> counterparts, which is the case.
>>>
>>> This looks like a bug to me. I would appreciate if someone else could a
>>> look at my data. Attached is the dump of the table and a screenshot of
>>> the
>>> line-network. If you load the dump, you might want to replace the owners
>>> with your own userid. In the screenshot, one line is marked as green.
>>> This
>>> is the line that is ignored by the ST_Polygonize() command.
>>>
>>> I used
>>> SELECT geom AS the_geom FROM ST_Dump((SELECT ST_Polygonize(the_geom) AS
>>> geom FROM admin.plz));
>>> as the SQL query.
>>>
>>> I'd appreciate any help on my problem, resp. an answer if this might be
>>> a
>>> bug or not.
>>>
>>> Thank you,
>>> Andreas
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> postgis-users mailing list
>>> postgis-users at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>
>>>       
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>     
>
>
>   



More information about the postgis-users mailing list