[Gdal-dev] Converting S-57 to GML and then parsing the GML document

[Frank Warmerdam]

On 6/27/05, avdimisglobal at yahoo.co.uk <avdimisglobal at yahoo.co.uk> wrote:
> Hi Guys (and Girls)
> 
> I have several S-57 ENC charts. I have converted one of them to GML using:
> 
> ogr2ogr –f "GML" test.gml test.000
> 
> The result is a 6 MB file containing features, which I presume to be
> correct.
> 
> I then parsed this GML and drew all the features to a PNG file. This is
> where the problem comes in. It seems that some of the coordinates in the GML
> document is incorrect. Some of the coordinates are not inside the area
> defined by:
> 
>   <gml:boundedBy>
>     <gml:Box>
>       <gml:coord><gml:X>-180</gml:X><gml:Y>15</gml:Y></gml:coord>
>       <gml:coord><gml:X>-116.5</gml:X><gml:Y>71.5</gml:Y></gml:coord>
>     </gml:Box>
>   </gml:boundedBy>
> 
> Also I don't know in what projection this is. I presume this to be WGS84 as
> the result I get when ignoring some coordinates and removing everything like
> Aids to Navigations etc look similar to what the original S-57 ENC looked
> like.
> 
> It seems that all the points are fine. The problem comes in with the lines
> and polygons.
> 
> In this feature:
> 
>   <gml:featureMember>
>     <Line fid="0">
>       <RCID>57</RCID>
>       <PRIM>2</PRIM>
>       <GRUP>2</GRUP>
>       <OBJL>30</OBJL>
>       <RVER>1</RVER>
>       <AGEN>550</AGEN>
>       <FIDN>134252534</FIDN>
>       <FIDS>2478</FIDS>
>       <LNAM>0226080087F609AE</LNAM>
> 
> <ogr:geometryProperty><gml:LineString><gml:coordinates>-139.299815,69.518647
> -139.382691,69.53233400000001 -139.422843,69.53669100000001
> -139.483763,69.53959500000001 -139.541914,69.53814300000001
> -139.573759,69.53862700000001 -139.595911,69.54298300000001
> -139.620833,69.551692 -139.645755,69.558463 -139.681753,69.562331
> -139.719135,69.566682 -139.753749,69.575864 -139.804977,69.584559
> -139.840975,69.58842300000001 -139.871435,69.59035400000001
> -139.904664,69.596148 -139.946201,69.602904 -139.998723,69.608375
> -140.027889,69.606765 -140.149729,69.599526 -140.227263,69.596148
> -140.329719,69.59035400000001 -140.398947,69.58794
> -140.432175,69.58890599999999 -140.490094,69.59194100000001
> -140.578705,69.596769 -140.6867,69.606421
> -140.809924,69.619444</gml:coordinates></gml:LineString></ogr:geometryProper
> ty>
>     </Line>
>   </gml:featureMember>
> 
> I would draw a line between point 1 & 2 and then between 2 & 3. Some of the
> coordinates are out of the box. If I ignore them everything looks fine. If I
> use them, I have lines all over the place.

Albert, 

I looked through the LineString above and don't see any
coordinates that appear to be outside the bounds.  Perhaps
you could be more specific about what vertices you think are in
error. 

> I have a similar problem with the polygons.
> 
> I'm using PHP to do it all, and had problems with the line being too long. I
> then added a check to drop all coordinates that does not have at least a
> lat/long. Some points have a third parameter - I presume this to be the Z
> value but am not quite sure what it is for.

Where I have non-zero elevation values I include them in the GML output. 
I think this would only occur for SOUNDG and DEPARE features. 

> It would be greatly appreciated if someone could shed a bit of light on the
> subject and help me out. I can provide the S-57 ENC and the GML (both are in
> the region of 6MB). I also have a screenshot of the S-57 chart and my own
> attempt in PNG format. They look similar but we specifically want the
> traffic separation schemes and buoys on the charts and also indicating sea,
> deep water, rivers and bridges.
> 
> One other thing - When viewing the original S-57 ENC it shows the names of
> cities, ports buildings etc. In the GML this is nowhere to be found. Is
> there a specific reason for this?

The S-57 reader has two modes of operation.  The simple mode is
what you are getting.  If you set things up so that OGR can find
the S-57 object class .csv files then you will get back features in
particular object classes (ie. SOUNDG, LNDARE, etc) with a variety
of object class specific attributes.  

Generally this is accomplished by defining the GDAL_DATA
environment variable to point to the gdal\data directory (where
files such as s57objectclasses.csv are found). 

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent