[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