So, if I understand correctly, you have coordinates of two points:
- origin (0,0) lat/lon
- center (0.5 * width, 0.5 * height) lat/lon
Is that correct?
What is "spacing"?
What
Jayesh Chaudhary wrote:
> Hi,
>
> Thanks for your reply. I think I have to gather more information here
> about the pro
The answer is - it depends. If you know the image projection (Mercator?)
and the precise scale of the image - it may be enough to have just one
point (think - a tile from Google maps).
To georeference an image in a general case (assuming the image has
simple linear proportions) requires at least 2
look?
ogr user wrote:
> Done, http://trac.osgeo.org/gdal/ticket/3610
>
> Frank Warmerdam wrote:
>
>> Mike,
>>
>> This would indeed be a useful change. I'd encourage you to file it in
>> Trac
>> a
Done, http://trac.osgeo.org/gdal/ticket/3610
Frank Warmerdam wrote:
> Mike,
>
> This would indeed be a useful change. I'd encourage you to file it in
> Trac
> and I'll look at incorporating it.
>
> Best regards,
___
gdal-dev mailing list
gdal-dev@lists.
If we assume that each S57 object corresponds to a real world entity -
in my opinion the best encoding would be a separate line object. I.e.
the main road is a point to point entity (as LineString supports) and
the spur from the east (such as the one from Ljubicevac) is a separate
line. That would
e. exterior ring was assembled
later than a first one) would be rearranged (in that exterior ring is
found and made the "exterior" ring) so that they could be drawn/handled
correctly using OGR geometry.
--Mike
Frank Warmerdam wrote:
> ogr user wrote:
>
> Mike,
>
> There is no e
Dear all and Frank,
I sent this patch out a few times before - never got any replies. It's
ok if you are not interested, though I have to say that it works very
well for me and improved handling of data. However, would someone kindly
confirm that you have looked at this patch, acknowledged it and
Sevencs succeed in many other aspects where others fail.
For example, they will actually parse and show older Netherlands chart
data (I still have a few cells from a year ago), which encoded polygon
edges using multiple SG2D fields, rather than a single SG2D field with
multiple values. Not only th
Correct me if I am wrong (I might be) but my reading of S-57 standard
(section 4.7 and thereabouts) is such that it does not provide for
multi-line geometries. Instead, it is suggested that if certain edges of
a line have to be "invisible" they should be masked by using appropriate
attribute. I hav
Dear all,
I've been looking around GDAL codebase and I can't see anything that
would deal with wide/multybyte characters for file names/paths on
Windows. Would you please confirm that on Windows GDAL will only be able
to open files with pure ASCII names, not international charset?
-M
___
In case anyone is interested, here is a simple patch for the polygon
outer ring issue. It's not a perfect way to detect the outer ring since
in some cases inner rings can have the *same* envelope area as the outer
ring, but in any practical chart case this works just fine. Calculating
actual ring a
I wonder if anyone here with a good knowledge of S57 format internals
can help me out on this issue.
OGR S57 parser seems to work quite well with most charts in NOAA ENC
data set. However, I found a feature on one of the charts that puzzles
me (to be specific, the chart is US5CA92M, the feature RC
Sorry to butt in with a question that must have been answered a few
times before.
I am looking for a solver (ready made or an algorithm to implement) to
derive an affine transformation matrix for a given coordinate
transformation based on a set of points with coordinates in each system.
Any help
In case anyone is interested, here is a patch that adds appropriate
handling of IntegerList field types to S57 parser. For backwards
compatibility it is only activated if specific option is passed to the
reader (actually to class registrar). This is for 1.5.3.
Frank Warmerdam wrote:
>
> De
field is an integer list.
May be it coud be done as an option, controlled by flag to a class
registrar (and default behavior be made as it was previously)?
Frank Warmerdam wrote:
>
> Dear OGR User,
>
> It appears the S57 code deliberately treats list attributes as simple
> strings.
I am using OGR to load S57 format files and it appears that at least for
some fields the field type is incorrectly returned by OGR. Fields of
type "integer list" (denoted L in s57attributes.csv, enumeration list)
are identified as string type by OGRField::GetType(). The problem with
that is that O
16 matches
Mail list logo
