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 robe, 11 years ago

Owner: changed from robe to strk

comment:2 by strk, 11 years ago

Status: newassigned

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.

comment:3 by strk, 11 years ago

See how you like r11852 (in trunk) — should be backported to 2.1 if you guys like it

comment:4 by tilt, 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 strk, 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 tilt, 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 strk, 11 years ago

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.