What could be the cause(es) of a ST_Collect(LINESTRING) not creating a valid POLYGON - geopaparazzi/Spatialite-Tasks-with-Sql-Scripts GitHub Wiki
What could be the cause(es) of a ST_Collect(LINESTRING) not creating a valid POLYGON?
- to understand why the creation of a POLYGON from LINESTRINGs fail
- it is important to fully understand what a valid POLYGON is considered to be
Some of these conditions are:
- the
ExternalRingof a POLYGON must be- closed
- the
Start/EndPointMUST be the same
- the
- the LINESTRING of the
ExternalRing- must NOT overlap itself
- if double LINESTRINGs exist
- they overlap themselves
- if double LINESTRINGs exist
- must NOT overlap itself
- closed
- for possible
InternalRings of a POLYGON- the same rules apply
- not only with themselves, but also with the
ExternalRing
- not only with themselves, but also with the
- the same rules apply
With these facts in mind, we will attempt to resolve this with existing commands
overlapping- this can be checked with
- using 'ST_IsSimple'
- this can be checked with
not closed- this can be checked with
- using 'ST_IsClosed'
ST_LineMerge(ST_Collect(soldner_segment))- is here your friend
- this can be checked with
Problem 01:
In this case the Geometry looks correct, no missing links to be seen
- the MULTILINESTRING in
spatialite_guishows 12 LINESTRINGs
SELECT name,ST_LineMerge(ST_Collect(soldner_segments)) AS merged_multilinestring
FROM berlin_geometries WHERE id_geometry IN (213);
spatialite_gui shows
SRID: 3068
Geometry type: MULTILINESTRING
#3 LINESTRINGs:
1) 55 vertices
2) 55 vertices
3) 193 vertices
Here the result is:
MULTILINESTRING-
with 3 LINESTRINGs
- I used
copy and paste(NOT thecopybutton) to copy theEWKTtext into an editor- this returns each POINT in one line (as apposed to the
copybutton which returns one line only)
- this returns each POINT in one line (as apposed to the
- there I confirmed, that for whatever reason, the same LINESTRING was being read in twice
- 2 x 55 POINTS
- I used
-
So the problem is to resolve the cause of the duplicate LINESTRING.
So with this (for this Database specific) Query, I looked at the collected linestring_segments:
3000-01-01: unknown future Date (present day borders)
SELECT *
FROM berlin_ortsteil_segments AS segments INNER JOIN
berlin_geometries AS geometries
WHERE
(
('213'=geometries.id_geometry) AND
(
('1920-10-01' BETWEEN segments.valid_since AND segments.valid_until) AND
(segments.belongs_to_01||','||segments.belongs_to_02 LIKE '%'||geometries.id_admin||'%')
)
);
I quickly saw that I have forgotten to remove a LINESTRING, that had been spitted into smaller portions.
- I invalidated the record, before deciding to delete it
UPDATE berlin_ortsteil_segments
SET
-- save the previous value, in case needed later
comment=valid_since||'-'||valid_until,
-- set impossible value to valid_since and valid_until
valid_since='3000-01-01',valid_until='3000-01-01'
WHERE id_segment = 67;
and rebuild the final table (where all possible combinations are build)
- date-range of
3000-01-01not being one of them
There I determined that this POLYGON (of 194) was build correctly
- only 51 more to go ...
Problem 02:
- this is the situation I was expecting when starting this page
- the
Problem 01turned up instead, so I did that first - this is the more common situation, with the most often used resolution
- the
2014-04-01: Mark Johnson, Berlin Germany