<div dir="ltr">Thanks for the explanation, Even. Makes sense to me.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 23, 2024 at 10:35 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div>
    <p>Sean,</p>
    <p>yes if there's a mix of data types, a String(JSON) field is
      reported to mean that.</p>
    <p>The only annoying thing is that for backward compatibility with
      past behaviour where we silently homogenized to a string, we
      didn't go to the point to actually quoting strings, so this isn't
      fully JSON compliant unfortunately</p>
    <p>I mean if we have out.json with:<br>
    </p>
    <p>{<br>
      "type": "FeatureCollection",<br>
      "features": [<br>
      { "type": "Feature", "properties": { "foo": "str" }, "geometry":
      null },<br>
      { "type": "Feature", "properties": { "foo": 0 }, "geometry": null
      },<br>
      { "type": "Feature", "properties": { "foo": ["a", "b"] },
      "geometry": null }<br>
      ]<br>
      }</p>
    <p>$ ogrinfo -al out.geojson -q<br>
      <br>
      Layer name: out<br>
      OGRFeature(out):0<br>
        foo (String(JSON)) = str<br>
      <br>
      OGRFeature(out):1<br>
        foo (String(JSON)) = 0<br>
      <br>
      OGRFeature(out):2<br>
        foo (String(JSON)) = [ "a", "b" ]<br>
      <br>
    </p>
    <p>In theory, we should report "str", not just str. A GDAL 4.0
      topic... ? Just recorded it in
      <a href="https://github.com/OSGeo/gdal/issues/8440#issuecomment-2368801316" target="_blank">https://github.com/OSGeo/gdal/issues/8440#issuecomment-2368801316</a><br>
    </p>
    <p>To actually answer your last question, this is a bit more subtle
      than the above. For example, if there's a mix of strings and array
      of strings, we report a StringList field. If there's a mix of
      integer and floating-point numbers, we report a Real field (which
      is OK since JSON has just a "numeric" type)</p>
    <p>Even<br>
    </p>
    <div>Le 23/09/2024 à 18:17, Sean Gillies via
      gdal-dev a écrit :<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>Hi all,</div>
        <div><br>
        </div>
        <div>The good thing about GeoJSON is that you don't need
          specialized GIS software to create it. The bad thing about
          GeoJSON is that people create it using software with none of
          the familiar GIS constraints.</div>
        <div><br>
        </div>
        <div>I've been looking at a collection of features that have the
          same set of properties (good), but one of the properties has a
          mix of strings (strings of digits, specifically) and unquoted
          numbers (0, specifically). In versions <= 3.5, GDAL detects
          this field's type to be "String". In versions >= 3.6, the
          field type is "String(JSON)". Is this intended behavior? Will
          all such fields be found to be "String(JSON)", or does it
          depend on their content?<br>
        </div>
        <br>
        <span class="gmail_signature_prefix">-- </span><br>
        <div dir="ltr" class="gmail_signature">Sean Gillies</div>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
gdal-dev mailing list
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
    </blockquote>
    <pre cols="72">-- 
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </div>

</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Sean Gillies</div>