Difference between revisions of "Talk:RFC-001"

From GeoJSON
Jump to: navigation, search
(Response to MPD)
 
(One intermediate revision by one other user not shown)
Line 15: Line 15:
 
# This is JSON, not GML, so we should (a) use commas and (b) use proper arrays and arrays of arrays.
 
# This is JSON, not GML, so we should (a) use commas and (b) use proper arrays and arrays of arrays.
 
# Drat. OK. Authors coming right up.
 
# Drat. OK. Authors coming right up.
 +
 +
== [[User:Mpd|Mpd]] Response to response ==
 +
# Good.
 +
# I don't understand: do you mean use PROJ.4 definition strings?  How about [http://portal.opengeospatial.org/files/?artifact_id=16339 OGC URN-s (with click-through licence)]?  Examples are: "urn:ogc:def:crs:OGC:1.3:CRS84" for the CRS formerly known as "EPSG:4326 with lat/lon axes order"; and "urn:ogc:def:crs:EPSG:6.3:26986" for "EPSG:26986".
 +
# [http://en.wikipedia.org/wiki/Image:EU_location_UK.png MultiPolygons] and [http://en.wikipedia.org/wiki/Image:Amazon_river_basin.png MultiLines] really do exist.
 +
# Anyone for [http://www.tradgames.org.uk/games/Quoits.htm Quoits]?
 +
# OK by me
 +
# Thanks.
 +
[[User:Mpd|Mpd]]
 +
 +
== [[User:AllanDoyle|AllanDoyle]] Response ==
 +
# Clearly this system of commenting on the comments is going to break down soon.
 +
# I mean literally taken from the file called 'epsg' which on my system installs into /Library/Frameworks/PROJ.framework/Versions/Current/Resources/proj/epsg. It looks sort of like this:
 +
# Unknown datum based upon the Airy 1830 ellipsoid
 +
<4001> +proj=longlat +ellps=airy +no_defs  <>
 +
# Unknown datum based upon the Airy Modified 1849 ellipsoid
 +
<4002> +proj=longlat +a=6377340.189 +b=6356034.447938534 +no_defs  <>
 +
# Unknown datum based upon the Australian National Spheroid
 +
<4003> +proj=longlat +ellps=aust_SA +no_defs  <>
 +
From that, the codes I mean are the ones in < >. There might be a better way to phrase this rule... But it boils down to not requiring people to find, read, and understand the EPSG tables themselves.
 +
# I believe you, let's add them. In fact, why not just say we'll allow geometries that have OGC WKT definitions. There must be a list somewhere.
 +
# If there's an OGC WKT, Quoits are in.
 +
#. Great.
 +
# You're welcome. (See, the numbering broke, and I don't have the wiki-fu to fix it).

Latest revision as of 05:13, 12 April 2007

Mpd Comments and Questions

  1. I'd prefer "crs" to "srs", the latter being out step with, for example, EPSG and OGC terminology. Ditto for "LineString" and "Line", and perhaps (although less so) "Envelope" and "Box"
  2. Why reference PROJ.4's EPSG tables and not the EPSG tables themselves? Do I sense a coordinate order holy war type thing going on?
  3. What about Multi[Point|LineString|Polygon] and GeometryCollection?
  4. What about Polygons with multiple rings? An earlier proposal handled this.
  5. How does a client determine whether the, for example, six ordinates in a Line/LineString are two x,y,z-s or three x,y-s?
  6. You suggested an "Authors" section, for CC reasons. Care to add one?

Mpd

AllanDoyle Response

  1. Shoot. I thought SRS was in vogue and CRS is out. Great. Let's go with crs. I have no preference with linestring, etc.
  2. PROJ vs EPSG. PROJ is what coders will see. They may never look at EPSG. Few people will use anything other than PROJ.
  3. Multi Schmulti, I always say. :)
  4. Rings Schmings... toss 'em in.
  5. This is JSON, not GML, so we should (a) use commas and (b) use proper arrays and arrays of arrays.
  6. Drat. OK. Authors coming right up.

Mpd Response to response

  1. Good.
  2. I don't understand: do you mean use PROJ.4 definition strings? How about OGC URN-s (with click-through licence)? Examples are: "urn:ogc:def:crs:OGC:1.3:CRS84" for the CRS formerly known as "EPSG:4326 with lat/lon axes order"; and "urn:ogc:def:crs:EPSG:6.3:26986" for "EPSG:26986".
  3. MultiPolygons and MultiLines really do exist.
  4. Anyone for Quoits?
  5. OK by me
  6. Thanks.

Mpd

AllanDoyle Response

  1. Clearly this system of commenting on the comments is going to break down soon.
  2. I mean literally taken from the file called 'epsg' which on my system installs into /Library/Frameworks/PROJ.framework/Versions/Current/Resources/proj/epsg. It looks sort of like this:
# Unknown datum based upon the Airy 1830 ellipsoid
<4001> +proj=longlat +ellps=airy +no_defs  <>
# Unknown datum based upon the Airy Modified 1849 ellipsoid
<4002> +proj=longlat +a=6377340.189 +b=6356034.447938534 +no_defs  <>
# Unknown datum based upon the Australian National Spheroid
<4003> +proj=longlat +ellps=aust_SA +no_defs  <>

From that, the codes I mean are the ones in < >. There might be a better way to phrase this rule... But it boils down to not requiring people to find, read, and understand the EPSG tables themselves.

  1. I believe you, let's add them. In fact, why not just say we'll allow geometries that have OGC WKT definitions. There must be a list somewhere.
  2. If there's an OGC WKT, Quoits are in.
  3. . Great.
  4. You're welcome. (See, the numbering broke, and I don't have the wiki-fu to fix it).
Retrieved from "http://wiki.geojson.org/index.php?title=Talk:RFC-001&oldid=54"