[gdal-dev] S57 dataset boundary issue
s duclos
sylvain_duclos at yahoo.com
Wed Oct 10 07:29:52 PDT 2012
Hi Nikhil,
I loaded US1GC09M//US1GC09M.000 .. it's huge :)
It's the Gulf of Mexico .. now where should I look ?
About the inner / outer ring. As I said before, I just assume that OGR
send me the outer ring first. And, up to now, my code is working fine.
rgds,
Sylvain.
----- Original Message -----
> From: Nikhil Sai Parupalli <nikhil.parupalli at iictechnologies.com>
> To: s duclos <sylvain_duclos at yahoo.com>; Frank Warmerdam <warmerdam at pobox.com>
> Cc: "gdal-dev at lists.osgeo.org" <gdal-dev at lists.osgeo.org>
> Sent: Wednesday, October 10, 2012 9:40:54 AM
> Subject: RE: [gdal-dev] S57 dataset boundary issue
>
> Could you try on this data set please
>
> Thanks and Regards
> Nikhil Sai Parupalli
>
>
>
> Note: Do not print this email until and unless it is really required. Save paper
> , stay Green
>
> ________________________________________
> From: s duclos [sylvain_duclos at yahoo.com]
> Sent: Wednesday, October 10, 2012 7:02 PM
> To: Nikhil Sai Parupalli; Frank Warmerdam
> Cc: gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] S57 dataset boundary issue
>
> Nikhil,
>
> I loaded your ENC.
>
> I see a number of depth area (DEPARE) and anchor zone area (ACHARE).
>
> But no inner ring!
>
> Is there an inner rings somewhere I should see?
>
>
>
> rgds,
>
> Sylvain.
>
>
>
> ----- Original Message -----
>> From: Nikhil Sai Parupalli <nikhil.parupalli at iictechnologies.com>
>> To: s duclos <sylvain_duclos at yahoo.com>; Frank Warmerdam
> <warmerdam at pobox.com>
>> Cc: "gdal-dev at lists.osgeo.org" <gdal-dev at lists.osgeo.org>
>> Sent: Wednesday, October 10, 2012 8:00:41 AM
>> Subject: RE: [gdal-dev] S57 dataset boundary issue
>>
>> Duclos,
>>
>> Please see this sample data attached.
>> So as per the code given by you we have tried and got result i.e able to
> find
>> out area
>>
>> some times it shows area<0 and some times area>0 hence we get CW and
> CCW.
>> But how do we classify in layer which is outer boundary and which is inner
>> boundary
>>
>>
>>
>>
>> Geometry testgeo = geomLAKARE.GetBoundary();
>> double area = 0;
>> for (int l = 0; l <
>> testgeo.GetPointCount() - 1; l++)
>> {
>> double x1 = testgeo.GetX(l);
>> double y1 = testgeo.GetY(l);
>> double x2 = testgeo.GetX(l + 1);
>> double y2 = testgeo.GetY(l + 1);
>> area += (x1 * y2) - (x2 * y1);
>> }
>>
>> Thanks and Regards
>> Nikhil Sai Parupalli
>>
>>
>>
>> Note: Do not print this email until and unless it is really required. Save
> paper
>> , stay Green
>>
>> ________________________________________
>> From: s duclos [sylvain_duclos at yahoo.com]
>> Sent: Tuesday, October 09, 2012 11:58 PM
>> To: Frank Warmerdam; Nikhil Sai Parupalli
>> Cc: gdal-dev at lists.osgeo.org
>> Subject: Re: [gdal-dev] S57 dataset boundary issue
>>
>> Frank & Nikhil,
>>
>>
>> Frank asked:
>>
>>> are, I'm not sure what I or others can do about
>>> the performance cost of checking.
>>
>>
>> If I understand the problem, then it cost nothing!
>>
>> You have to check the winding while loading a OGRGeometryH
>> like so:
>> double area = 0;
>> for (unsigned int i=0; i<vert_count-1; i++) {
>> double x1 = OGR_G_GetX(hRing, i);
>> double y1 = OGR_G_GetY(hRing, i);
>> double x2 = OGR_G_GetX(hRing, i+1);
>> double y2 = OGR_G_GetY(hRing, i+1);
>> area += (x1*y2) - (x2*y1);
>> }
>>
>>
>> If the area < 0 then it is CW (clockwise) and > 0 is CCW (Counter
> CW).
>>
>> Note that in S57 the exterior ring must be CW and
>> interior ring are CCW.
>>
>> But in S57 there is no order between rings. So interior ring
>> might come first. I think WKT fix this. In my code I assume
>> that OGR place the exterior ring first.
>>
>>
>> We have been trough this before. At the time the question
>>
>> was if S57 allow for many exterior ring for the same poly.
>>
>> I guess it all depend on HO and how they encode the data.
>>
>> I'm using mostly Canadian ENC and found no problem.
>>
>> But other HO might encode ENC differently ..
>>
>>
>>
>>
>> rdgs,
>>
>>
>> Sylvain Duclos.
>>
>>
>>
>>
>>
>>
>>
>>> ________________________________
>>> From: Frank Warmerdam <warmerdam at pobox.com>
>>> To: Nikhil Sai Parupalli <nikhil.parupalli at iictechnologies.com>
>>> Cc: "gdal-dev at lists.osgeo.org"
> <gdal-dev at lists.osgeo.org>
>>> Sent: Tuesday, October 9, 2012 12:25:29 PM
>>> Subject: Re: [gdal-dev] S57 dataset boundary issue
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Oct 8, 2012 at 10:28 PM, Nikhil Sai Parupalli
>> <nikhil.parupalli at iictechnologies.com> wrote:
>>>
>>> HI All,
>>>> ,
>>>>
>>>> Thanks for the reply in below data
>>>>
>>>> NAME_RCNM (IntegerList) = (7:130,130,130,130,130,130,130)
>>>> NAME_RCID (IntegerList) = (7:691,391,690,52,1336,1503,1512)
>>>> ORNT (IntegerList) = (7:2,2,2,2,1,1,1)
>>>> USAG (IntegerList) = (7:1,1,1,1,1,1,1)
>>>> MASK (IntegerList) = (7:255,255,255,255,255,255,255)
>>>>
>>>> RCID 691 ORNT has 2 and USAG is 1 based on this data we could
> identify
>> that RCID 691 is of exterior boundary with reverse direction.
>>>>
>>>> So if I have 1000 RCID in NAME_RCID which is vise versa for the
> above
>> condition I need to display that RCIDS list as errors.
>>>> So it makes 1000 conditional checks hence reducing performance.
>>>>
>>>> Please let us know further.
>>>
>>>
>>> Nikhil,
>>>
>>>
>>> I'm afraid I don't follow your point. Are you trying to
>>> do some sort of ring orientation validation and identify
>>> ones that don't match your expectations? And you
>>> are concerned about the performance cost?
>>>
>>>
>>> I don't know why you are doing this, and if you
>>> are, I'm not sure what I or others can do about
>>> the performance cost of checking.
>>>
>>>
>>> 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 Software Developer
>>>
>>>
>>> _______________________________________________
>>> gdal-dev mailing list
>>> gdal-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>>>
>>
>
More information about the gdal-dev
mailing list