<div>So we seem to have 3 divergent options to provide a work around:</div><div><br></div><div>1. Expose fieldmap setting to let the user decide the order of the fields to be copied.</div><div>2. Modify GetFieldIndex to provide the name based lookup by the truncated name (for the shape driver specifically)</div>
<div>3. Provide an option to instruct ogr2ogr to consider the source and the destination has the same field structure (order).</div><div><br></div><div>Which would be the most reasonable?</div><div><br></div><div>I personally in favour of #3 or #1.  #3 is easier to implement, but #1 is more customizable.</div>
<div>With regards to #2 we might continue to encounter non trivial matches.</div><div><br></div><div>Best regards,</div><div><br></div><div>Tamas </div><div><br></div><div><br></div><div><br></div><br><br><div class="gmail_quote">
2013/2/25 Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le lundi 25 février 2013 16:57:08, Tamas Szekeres a écrit :<br>
> Hi All,<br>
><br>
> Related to issue #3247 <<a href="http://trac.osgeo.org/gdal/ticket/3247" target="_blank">http://trac.osgeo.org/gdal/ticket/3247</a>> we<br>
<div><div class="h5">> experienced, that if we use ogr2ogr to append source data to a shapefile<br>
> destination (by using the -append flag) and field name truncation is taking<br>
> place, the corresponding values are not copied.<br>
><br>
> This is because when setting up the field index map (in ogr2ogr) the<br>
> destination (truncated) field indexes are searched by the name of of the<br>
> source fields (the long names).<br>
><br>
> Since it's not always trivial to find the correct fields by names, how<br>
> about exposing the field map itself as an option, something like:<br>
><br>
> ogr2ogr -append -f "ESRI Shapefile" -fieldmap "0,1,2,3,4,5" destination.shp<br>
>  [source]<br>
><br>
><br>
> Would that workaround be sufficient?<br>
<br>
</div></div>That would certainly work, although not particularly user friendly, but<br>
shapefiles are not that user friendly with their various limitations.<br>
<br>
Perhaps you could just work with spatialite DBs as intermediate and convert to<br>
shapefile at the end if it is really needed ?<br>
<br>
A potential alternative to -fieldmap would be to have :<br>
<br>
class OGRLayer:<br>
{<br>
   public:<br>
          virtual int GetFieldIndex(const char* pszFieldname);<br>
}<br>
<br>
int OGRLayer::GetFieldIndex(const char* pszFieldname)<br>
{<br>
        return GetLayerDefn()->GetFieldIndex(pszFieldname);<br>
}<br>
<br>
int OGRShapeLayer::GetFieldIndex(const char* pszFieldname)<br>
{<br>
        int idx = OGRLayer::GetFieldIndex(pszFieldname);<br>
        if( idx >= 0 )<br>
                return idx;<br>
        /* otherwise implement here truncation logic to find best match */<br>
        /* caution: if there are several potential matches (for example<br>
verylongcolumnname1 being truncated to verylongna and verylongcolumnname2<br>
truncated to verylong~1) and you are looking for verylongcolumnXXX then return<br>
-1 */<br>
}<br>
<br>
><br>
><br>
> Best regards,<br>
><br>
> Tamas<br>
</blockquote></div><br>