Repository navigation
MapSmith 0.6.1
A small release on the day of 0.6.0. It moves no manifest key and changes no
answer that 0.6.0 got right: it stops a refusal 0.6.0 introduced from firing on
a layer written in 0..360 longitudes, gives two refusals the right way out, and
declares the specification's current draft.
Changed
- Records declare
spec_version1.0.0-draft.8. Two drafts in one day,
both narrowings of where a producer may add a key: draft.7 requires every
key ofcrs_decisionsthe specification does not define to be named
x-<producer>:<name>, which it had left to one reading of an ambiguous
sentence, and draft.8 carries the rule insidetransformation,
round_tripandrepairs[]. MapSmith already named every one of them that
way, so no key moves: a reader keying on the label sees draft.8, a reader
keying on fields sees nothing change. The vendored schema and validator are
draft.8's, and the conformance sweep validates every writer's record
against them.
Fixed
- A layer written in 0..360 longitudes had its seam in the wrong place.
The antimeridian refusal of 0.6.0 took the edge of the plane to be -180/180,
so the world written asbox(0, -90, 360, 90)was refused, the way 0.6.0's
own review had found Antarctica refused in -180..180. For such a layer the
edge is 0/360, and the ring that really is drawn naively crosses the prime
meridian: the refusal now says so and tells its author to split there, where
it used to send them to 180. A layer is read as 0..360 when it has no
negative longitude and some beyond 180 -- not whenever one vertex passes
180, which the first version of this fix did, and which refused the world
beside a polygon overshooting 180 by 1e-7. Edges along either pair of seams
are exempt in every layer. - "No UTM zone" said the data was centred on the antimeridian, whatever the
data, and offered no way out. The realistic cause is latitude — UTM stops
at 84N and 80S — and the message now says that and names a polar CRS to use
(UPS, or a polar stereographic), for data that crosses 180 and for data that
does not.