Opened 11 years ago
Closed 11 years ago
#2444 closed enhancement (fixed)
Wrong example in asTopoJON manual
Reported by: | tilt | Owned by: | strk |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.1.1 |
Component: | documentation | Version: | 2.1.x |
Keywords: | astopojson | Cc: |
Description
TopoJson seems to require delta values in the coordinates instead of pure coordinates given in the example. Additionally, the indexing in arcs is wrong and some comma's are missing in the example.
A better output example would be:
{ "type": "Topology", "transform": { "scale": [1,1], "translate": [0,0] }, "objects": { "P3P4": { "type": "MultiPolygon", "arcs": [[[0]],[[1,2,3,4,5,6]]]} }, "arcs": [ [[25,30],[6,0],[0,10],[-14,0],[0,-10],[14,0]], [[35,14],[0,-8]], [[35,6],[12,0]], [[47,6],[0,8]], [[47,14],[0,8]], [[47,22],[-12,0]], [[35,22],[0,-8]] ]}
To get the deltas from the coordinates is a bit tricky. Here's a suggestion that works but it's open for improvement:
WITH points as ( SELECT nextval('mycounter') as id, m.edge_id as groupid, (st_dumppoints(geom)).geom FROM edgemap m, <yourTopoTable>.edge e WHERE e.edge_id = m.edge_id ), compare as ( SELECT id, groupid, first_value(geom) OVER (PARTITION BY groupid ORDER BY id ) geom0, (geom) geom1, (lead(geom) OVER (PARTITION BY groupid ORDER BY id )) geom2 FROM points ) SELECT '[[' || ST_X(geom0) || ','||ST_Y(geom0)|| '],' || string_agg('[' || ROUND(ST_X(geom2) - ST_X(geom1)) || ',' || ROUND(ST_Y(geom2) - ST_Y(geom1)) || ']',',') || '],' as arc FROM compare
Change History (7)
comment:1 by , 11 years ago
Owner: | changed from | to
---|
comment:2 by , 11 years ago
Status: | new → assigned |
---|
comment:3 by , 11 years ago
See how you like r11852 (in trunk) — should be backported to 2.1 if you guys like it
comment:4 by , 11 years ago
Strk, it works for me, and relatively fast. Thanks for the update. Looking at the SQL code however, I think you're right about serving it as a new function in the future. This might be beyond the comprehension of an average user and basically it's more about parsing than about calculating.
Btw: Doesn't it have some overlap with how tinywkb (from Nicklas Avéns) would behave? That might be a starting point for AsTopoJSONArc()
comment:5 by , 11 years ago
Yes, I think there'll be some common code with tiniwkb. But more than implementation I think it's important to decide about the interface. Do we really want a new signature like AsTopoJSONArc or should we add a new flag to the existing ST_AsJSON ?
comment:6 by , 11 years ago
You mean ST_AsGeoJson right? Wouldn't that imply breaking open the GeoJson format? Putting in delta's instead of full coordinates is an interesting option though… what would be the right place to discuss that? I'd be happy to start a topic. In the meantime your solution in the manual is satisfying for me. Ticket may be closed IMO.
comment:7 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Yes, I meant ST_AsGeoJSON. Good place for discussing this is the postgis-devel mailing list ( http://lists.osgeo.org/mailman/listinfo/postgis-devel ). Closing the ticket.
It is indeed tricky, so much that I wonder if we should add an AsTopoJSONArc() function. Your version seems to be computing deltas always from the first point, rather than from the precedent point.