I'm very shortly going to need to very quickly implement simple geocoding and vector graphics of roads and other features.
Are there other ways to include geocoding and basic mapping in a mobile (no internet) device?
]]>The primary advantage of TopoJSON is size. By eliminating redundancy and using a more efficent fixed-precision integer encoding of coordinates, TopoJSON files are often an order of magnitude smaller than GeoJSON files. The secondary advantage of TopoJSON files is that encoding the topology has useful applications, such as topology-preserving simplification (similar to MapShaper) and automatic mesh generation (as in the state-state boundaries in this example choropleth).
These advantages come at a cost: a more complex file format. In JavaScript, for example, you’d typically use the TopoJSON client library to convert TopoJSON to GeoJSON for use with standard tools such as d3.geoPath. (In Python, you can use topojson.py.) Also, TopoJSON’s integer format requires quantizing coordinates, which means that it can introduce rounding error if you’re not careful. (See the documentation for topojson -q
.)
For server-side manipulation of geometries that does not require topology, then GeoJSON is probably the simpler choice. Otherwise, if you need topology or want to send the geometry over the wire to a client, then use TopoJSON.
]]>An inner join of A and B gives the result of A intersect B, i.e. the inner part of a Venn diagram intersection.
An outer join of A and B gives the results of A union B, i.e. the outer parts of a Venn diagram union.
Examples
Suppose you have two tables, with a single column each, and data as follows:
A B
- -
1 3
2 4
3 5
4 6
Note that (1,2) are unique to A, (3,4) are common, and (5,6) are unique to B.
Inner join
An inner join using either of the equivalent queries gives the intersection of the two tables, i.e. the two rows they have in common.
select * from a INNER JOIN b on a.a = b.b;
select a.*, b.* from a,b where a.a = b.b;
a | b
--+--
3 | 3
4 | 4
Left outer join
A left outer join will give all rows in A, plus any common rows in B.
select * from a LEFT OUTER JOIN b on a.a = b.b;
select a.*, b.* from a,b where a.a = b.b(+);
a | b
--+-----
1 | null
2 | null
3 | 3
4 | 4
Right outer join
A right outer join will give all rows in B, plus any common rows in A.
select * from a RIGHT OUTER JOIN b on a.a = b.b;
select a.*, b.* from a,b where a.a(+) = b.b;
a | b
-----+----
3 | 3
4 | 4
null | 5
null | 6
Full outer join
A full outer join will give you the union of A and B, i.e. all the rows in A and all the rows in B. If something in A doesn't have a corresponding datum in B, then the B portion is null, and vice versa.
select * from a FULL OUTER JOIN b on a.a = b.b;
a | b
-----+-----
1 | null
2 | null
3 | 3
4 | 4
null | 6
null | 5
]]>The best guidance one can offer is to be fully aware of the expected axis order of each component in your software stack. PostGIS expects lng/lat. WFS 1.0 uses lng/lat, but WFS 1.3.0 defers to the standard and uses lat/lng. GeoTools defaults to lat/lng but can be overridden with a system property.
The GeoTools docs on the history and explanation of the problem are worth a read: http://docs.geotools.org/latest/userguide/library/referencing/order.html
]]>