<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Jukka,<br>
    <br>
    On 30/03/15 09:46, Jukka Rahkonen wrote:<br>
    <span style="white-space: pre;">> Homme Zwaagstra <hrz
      <at> geodata.soton.ac.uk> writes:<br>
      ><br>
      >><br>
      >><br>
      >>     <br>
      >>     P.S. on the proposal below, perhaps things could be
      'standardised'<br>
      >>     even more by<br>
      >>     including the cornerCoordinates in both wgs84 and
      native coordinate<br>
      >>     systems<br>
      >>     (much like gdalinfo does at the moment).  In this way
      you can be<br>
      >>     guaranteed of<br>
      >>     getting geojson output in its default coordinate
      system.  e.g.:<br>
      >>     { "cornerCoordinates":<br>
      >>       { "wgs84": ... GeoJSON FeatureCollection
      transformed to EPSG:4326<br>
      >>     ...,<br>
      >>         "native: ... GeoJSON FeatureCollection in native
      coordinates ...<br>
      >>       }<br>
      >>     }<br>
      >>     Best regards,<br>
      >>     Homme   <br>
      ><br>
      ><br>
      > Hi,<br>
      ><br>
      > Do you want to open this can of worms? Hardcore GeoJSON folks
      will tell that<br>
      > "GeoJSON FeatureCollection in native coordinates" does not
      exist because<br>
      > newest GeoJSON draft wants to support only one CRS which is
      WGS84<br>
      > Longitude-Latitude. From<br>
      >
      <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-butler-geojson/?include_text=1">https://datatracker.ietf.org/doc/draft-butler-geojson/?include_text=1</a><br>
      ><br>
      > "Other coordinate reference systems, including ones described
      by CRS<br>
      > objects of the kind defined in [GJ2008] are NOT RECOMMENDED."<br>
      ><br>
      > And then hardcore OGC standard folks will tell that the axis
      order of<br>
      > coordinates must follow the official EPSG:definitions.<br>
      ><br>
      > At least for me as a user of ogrinfo and gdalinfo the bounds
      in the native<br>
      > units are the ones which I need. A few times in a year the
      geographic bounds<br>
      > may be useful but I have not even thought before writing this
      mail that<br>
      > ogrinfo does not report the WGS84 bounds while gdalinfo does.
      I deal also<br>
      > often with data with unknown CRS like shapefiles without .prj
      and tiff+tfw<br>
      > files. I suppose that bounds of those cannot be expressed as
      GeoJSON<br>
      > FeatureCollections according to the new draft because nobody
      knows how to<br>
      > re-project from unknown to WGS84 and back..</span><br>
    <br>
    The fact that it is a can of worms is what made me think that
    providing both<br>
    options would be helpful from a practical point of view: many tools
    expect<br>
    geojson to be in wgs84 (in which case use the transformed object)
    but equally as<br>
    in your use case it is important to be able to access the native
    coordinates.<br>
    <br>
    I think the key point I wanted to make is that having the
    coordinates in geojson<br>
    format makes them more generally accessible, whatever the CRS, but
    if there is<br>
    also the option to meet wider (geojson) expectations by also having
    them in<br>
    wgs84 then that can be no bad thing.<br>
    <br>
    Because the JSON output is quite high level it would be nice to not
    to have to<br>
    add additional steps such as coordinate transformations to make more
    general use<br>
    of the data.  E.g. it would be nice to just be able to pull out the
    extent of a<br>
    raster and have it available in a 'known' usable format, such as
    adding it as a<br>
    GIS layer, database extent etc.<br>
    <br>
    <span style="white-space: pre;">><br>
      ><br>
      > I think that the original RFC keeps things simple by relying
      on plain XML<br>
      > and JSON and not mixing GML and GeoJSON into the play.
      However, I am not a<br>
      > programmer so I may be all wrong.</span><br>
    <br>
    The geojson and xml is designed to be ingested by programs: I'm in
    favour of<br>
    making this process as easy as possible using standard tools and
    formats.<br>
    <br>
    I didn't mention GML (the XML component doesn't interest me as much)
    but now<br>
    that you have... ;)<br>
    <br>
    Best regards,<br>
    <br>
    Homme<br>
    <br>
    <span style="white-space: pre;">><br>
      ><br>
      > -Jukka Rahkonen-<br>
      ><br>
      ><br>
      ><br>
      > _______________________________________________<br>
      > gdal-dev mailing list<br>
      > <a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
      > <a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></span><br>
    <br>
    <br>
  </body>
</html>