OGRGeometry::Distance

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

OGRGeometry::Distance

Matthew Perry-2
Hi folks,

  I'm new to the list so I'll just introduce myself real quick. I've been doing GIS and cartography for 4 years at Humboldt State University as a Natural Resources major and, although it's not my background per se, I've been getting heavily into programming these past few months. Most of my web mapping stuff is PHP/Mapscript but I've begun really like python/OGR/GDAL for doing my data processing.

  Anyways, I've run into a bit of an issue with the OGRGeometry::Distance method. Check out the following script:

    import ogr
    # Create some test geometries
    wkt = 'POINT(1 1)'
    g1 = ogr.CreateGeometryFromWkt(wkt)
    wkt = 'POINT(2 1)'
    g2 = ogr.CreateGeometryFromWkt(wkt)

    b = g1.Buffer(2)
    # Works fine so we know geos is enabled
 
    d = g1.Distance(g2)
    # fails ... "Attribute Error: Geometry instance has no attribute 'Distance'"

According to the docs at http://gdal.maptools.org/ogr/classOGRGeometry.html this should work, right? Or have there been recent changes that break this method? Are there any updated docs anywhere? I'm using gdal 1.3.0 packaged with FWTools 0.9.9 on ubuntu linux.

Thanks for helping me out.

--
Matt Perry
[hidden email]
http://www.perrygeo.net
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: OGRGeometry::Distance

Frank Warmerdam
On 9/18/05, Matthew Perry <[hidden email]> wrote:

> Hi folks,
>  
>    I'm new to the list so I'll just introduce myself real quick. I've been
> doing GIS and cartography for 4 years at Humboldt State University as a
> Natural Resources major and, although it's not my background per se, I've
> been getting heavily into programming these past few months. Most of my web
> mapping stuff is PHP/Mapscript but I've begun really like python/OGR/GDAL
> for doing my data processing.
>  
>    Anyways, I've run into a bit of an issue with the OGRGeometry::Distance
> method. Check out the following script:
>  
>      import ogr
>      # Create some test geometries
>      wkt = 'POINT(1 1)'
>      g1 = ogr.CreateGeometryFromWkt(wkt)
>      wkt = 'POINT(2 1)'
>      g2 = ogr.CreateGeometryFromWkt(wkt)
>  
>      b = g1.Buffer(2)
>      # Works fine so we know geos is enabled
>  
>      d = g1.Distance(g2)
>      # fails ... "Attribute Error: Geometry instance has no attribute
> 'Distance'"
>
>  According to the docs at
> http://gdal.maptools.org/ogr/classOGRGeometry.html this
> should work, right? Or have there been recent changes that break this
> method? Are there any updated docs anywhere? I'm using gdal 1.3.0 packaged
> with FWTools 0.9.9 on ubuntu linux.

Matt,

I'm afraid the Distance method didn't make it into the OGR Python bindings
for some reason.

I have added it in CVS.

It turns out all that was missing was the wrapper method so you can just add
the Distance method in FWTools0.9.9/pymod/ogr.py near the bottom.  
Something like:

    def SymmetricDifference( self, other ):
        geom = _gdal.OGR_G_SymmetricDifference( self._o, other._o )
        if geom is not None and geom != 'NULL':
            return Geometry( obj = geom, thisown = 1 )
        else:
            return None
       
    def Distance( self, other ):
        return _gdal.OGR_G_Distance( self._o, other._o )

def BuildPolygonFromEdges( edges, bBestEffort=0, bAutoClose=0, Tolerance=0 ):
    _o = _gdal.OGRBuildPolygonFromEdges( edges._o, bBestEffort, bAutoClose,
                                         Tolerance )
    if _o is not None and _o != 'NULL':
        return Geometry( obj = _o, thisown = 1 )
    else:
        return None;

Best regards,

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

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: OGRGeometry::Distance

Schuyler Erle
In reply to this post by Matthew Perry-2
* On 17-Sep-2005 at 10:53PM PDT, Matthew Perry said:
>
> According to the docs at
> http://gdal.maptools.org/ogr/classOGRGeometry.htmlthis should work,
> right? Or have there been recent changes that break this
> method? Are there any updated docs anywhere? I'm using gdal 1.3.0 packaged
> with FWTools 0.9.9 on ubuntu linux.

I think this is an oversight in the current OGR bindings for Python. I
fixed this locally by copying and pasting another function in ogr.py
and renaming the function and the function it calls internally. I
forgot, however, to send patches back to Frank. (Oops. Don't be a bad
F/OSS user like me, OK?) :-)

SDE
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: OGRGeometry::Distance

Howard Butler-2
In reply to this post by Matthew Perry-2
Re: [Gdal-dev] OGRGeometry::Distance
Matthew,

It is just an oversight that the Python OGR.Geometry.Distance function is not implemented in ogr.py.  It *is* in the wrapper though.  Here is what I do to get a Distance function.  I usually put it after all of my imports at the top.

try:
    ogr.Geometry.Distance
except AttributeError:
    def Distance(self, other):
        dist = _gdal.OGR_G_Distance(self._o, other._o);
        return dist
    ogr.Geometry.Distance = Distance


Howard


At 10:50 PM -0700 9/17/05, Matthew Perry wrote:
Hi folks,

  I'm new to the list so I'll just introduce myself real quick. I've been doing GIS and cartography for 4 years at Humboldt State University as a Natural Resources major and, although it's not my background per se, I've been getting heavily into programming these past few months. Most of my web mapping stuff is PHP/Mapscript but I've begun really like python/OGR/GDAL for doing my data processing.

  Anyways, I've run into a bit of an issue with the OGRGeometry::Distance method. Check out the following script:

    import ogr
    # Create some test geometries
    wkt = 'POINT(1 1)'
    g1 = ogr.CreateGeometryFromWkt(wkt)
    wkt = 'POINT(2 1)'
    g2 = ogr.CreateGeometryFromWkt(wkt)

    b = g1.Buffer(2)
    # Works fine so we know geos is enabled
 
    d = g1.Distance(g2)
    # fails ... "Attribute Error: Geometry instance has no attribute 'Distance'"

According to the docs at http://gdal.maptools.org/ogr/classOGRGeometry.html this should work, right? Or have there been recent changes that break this method? Are there any updated docs anywhere? I'm using gdal 1.3.0 packaged with FWTools 0.9.9 on ubuntu linux.

Thanks for helping me out.

--
Matt Perry
[hidden email]
http://www.perrygeo.net

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev


_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: OGRGeometry::Distance

Matthew Perry-2
In reply to this post by Frank Warmerdam
Frank, Howard and Schuyler and all,

On 9/18/05, Frank Warmerdam <[hidden email]> wrote:

I'm afraid the Distance method didn't make it into the OGR Python bindings

  Thanks for your all your suggestions. I added the Distance function to ogr.py as Frank suggested. The try/except block suggested by Howard is a really good idea since it will ensure backwards compatibility.

  So as I was going through the methods of the Geometry class, I noticed that there were a bunch of them (GetPointCount, GetX, GetY, GetZ, SetPoint, AddPoint, more?) that aren't documented in the official OGRGeometry docs.  Are the python bindings that significantly different than the C++ methods? If so, It might be worth considering using a tool like epydoc to create GDAL/OGR documentation specifically for python. I'd be willing to head this up if there were significant interest in doing so.

--
Matt Perry
[hidden email]
http://www.perrygeo.net
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: OGRGeometry::Distance

Frank Warmerdam
On 9/18/05, Matthew Perry <[hidden email]> wrote:
>    So as I was going through the methods of the Geometry class, I noticed
> that there were a bunch of them (GetPointCount, GetX, GetY, GetZ, SetPoint,
> AddPoint, more?) that aren't documented in the official OGRGeometry docs.
> Are the python bindings that significantly different than the C++ methods?
> If so, It might be worth considering using a tool like epydoc to create
> GDAL/OGR documentation specifically for python. I'd be willing to head this
> up if there were significant interest in doing so.

Matt,

The Python (and other swig bindings) use the "simplified" C API
for accessing geometry.  The downside to this is it doesn't match the
C++ API well and isn't really properly documented.  It would nice
to have some generic docs that would explain this for all the swig
interfaces to OGR Geometries.

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

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: OGRGeometry::Distance

Ari Jolma
Frank Warmerdam kirjoitti:

>On 9/18/05, Matthew Perry <[hidden email]> wrote:
>  
>
>>   So as I was going through the methods of the Geometry class, I noticed
>>that there were a bunch of them (GetPointCount, GetX, GetY, GetZ, SetPoint,
>>AddPoint, more?) that aren't documented in the official OGRGeometry docs.
>>Are the python bindings that significantly different than the C++ methods?
>>If so, It might be worth considering using a tool like epydoc to create
>>GDAL/OGR documentation specifically for python. I'd be willing to head this
>>up if there were significant interest in doing so.
>>    
>>
>
>Matt,
>
>The Python (and other swig bindings) use the "simplified" C API
>for accessing geometry.  The downside to this is it doesn't match the
>C++ API well and isn't really properly documented.  It would nice
>to have some generic docs that would explain this for all the swig
>interfaces to OGR Geometries.
>  
>

It might be confusing to document the "intermediate" C/C++ API, which is
between GDAL C++ and the swig-based language bindings, if that's what
you mean. I mean from the users' point of view. However, all the
swig-based language interfaces should be as similar as possible (or at
least implement the common base), but I'm not sure if their docs can be
based on some common meta information. Matthew, I wrote initial docs for
the swig/Perl bindings, they at least list all existing methods, I don't
know if they are on the cvs yet. Frank, thinking about this, I may want
a cvs commit rights to update and maintain these docs.

Frank mentioned somewhere that the files in cvs can be seen on the web
but I didn't find a link on gdal.maptools.org?

Ari

>Best regards,
>  
>


--
Prof. Ari Jolma
Kartografia ja Geoinformatiikka / Cartography and Geoinformatics
Teknillinen Korkeakoulu / Helsinki University of Technology
POBox 1200, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: OGRGeometry::Distance

Matthew Perry-2
Ari,

On 9/18/05, Ari Jolma <[hidden email]> wrote:
It might be confusing to document the "intermediate" C/C++ API, which is
between GDAL C++ and the swig-based language bindings, if that's what
you mean. I mean from the users' point of view.

I agree. I think the C++ and the C methods are already documented seperately. What we really need is docs for the swig interface.

However, all the
swig-based language interfaces should be as similar as possible (or at
least implement the common base), but I'm not sure if their docs can be
based on some common meta information. Matthew, I wrote initial docs for
the swig/Perl bindings, they at least list all existing methods,

Wow. I didn't even know there were ogr/perl bindings! That's OK for me since looking at Perl code makes my head hurt ;-) Are they available anywhere? How did you generate these docs?

I was thinking of an automated method to regenerate the docs every time the bindings changed. Python offers a very simple way to do this with the epydoc module. You document the classes directly in the code itself using their basic epytext markup:

    def Distance( self, other ):
       '''
       Returns the minimum distance between this geometry and another.
       @type other: OGR.Geometry
       @param other: Geometry to calculate distance to.
       @rtype: float
       @return: Distance between Geometries
       '''
       return _gdal.OGR_G_Distance( self._o, other._o )

Then run one command to generate the docs:

     epydoc -o /www/ogr_docs/ ogr

And you have complete class documentation. I've posted the example at http://perrygeo.net/ogr_docs/index.html . Of course the OGR.Geometry.Distance method was the only one I documented so it looks a little sparse but you get the idea.

This technique would be acceptable IF all the swig interfaces were kept in sync with the Python version.

Are there similar/better methods out there for maintaing perl docs? It seems that a solution where we maintain the class documentation in the code itself would be preferable to maintaining a separate document but this may be my inexperience talking.

Any thoughts?
--
Matt Perry
[hidden email]
http://www.perrygeo.net
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: OGRGeometry::Distance

Ari Jolma
Matthew Perry wrote:

>
> Wow. I didn't even know there were ogr/perl bindings! That's OK for me
> since looking at Perl code makes my head hurt ;-) Are they available
> anywhere? How did you generate these docs?

well, looking at Python code makes my heart cry ;-)

temporarily at: http://map.hut.fi/gdal-perl/

these docs are hand-made pods (well, I used some throw-away scripts to
make the skeleton), converted to HTML with pod2html

>
> I was thinking of an automated method to regenerate the docs every
> time the bindings changed. Python offers a very simple way to do this
> with the epydoc module. You document the classes directly in the code
> itself using their basic epytext markup:


With Perl you can add docs to a module similarly and when the module is
installed, the doc is automagically available as a man page. With swig
though, it seems that the pod has to written into a separate file.

>
> And you have complete class documentation. I've posted the example at
> http://perrygeo.net/ogr_docs/index.html . Of course the
> OGR.Geometry.Distance method was the only one I documented so it looks
> a little sparse but you get the idea.


ok, nice, similar to what javadoc does (but frames...grr), the pod2html
is a bit old-fashioned but I don't know of anything more modern, I use
the man pages or code usually

>
> This technique would be acceptable IF all the swig interfaces were
> kept in sync with the Python version.


I'm missing parameter types in the methods, for example in Perl, the
CopyLayer method's param options is a reference to a list of strings,
and that is not obvious from that doc. That kind of info is necessary
for the programmer (scripter).

>
> Are there similar/better methods out there for maintaing perl docs? It
> seems that a solution where we maintain the class documentation in the
> code itself would be preferable to maintaining a separate document but
> this may be my inexperience talking.


I like the idea of having the doc right next to the code and am
disappointed because swig does not seem to allow that in the case of
Perl. In this case we, however, would be best of having the docs in the
swig interface files (ogr.i etc), but they would need to be written in
language-independent way. I'm not sure if that's doable.

Ari

>
> Any thoughts?
> --
> Matt Perry
> [hidden email] <mailto:[hidden email]>
> http://www.perrygeo.net 



--
Prof. Ari Jolma
Kartografia ja Geoinformatiikka / Cartography and Geoinformatics
Teknillinen Korkeakoulu / Helsinki University of Technology
POBox 1200, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: OGRGeometry::Distance

Frank Warmerdam
In reply to this post by Ari Jolma
On 9/19/05, Ari Jolma <[hidden email]> wrote:

> It might be confusing to document the "intermediate" C/C++ API, which is
> between GDAL C++ and the swig-based language bindings, if that's what
> you mean. I mean from the users' point of view. However, all the
> swig-based language interfaces should be as similar as possible (or at
> least implement the common base), but I'm not sure if their docs can be
> based on some common meta information. Matthew, I wrote initial docs for
> the swig/Perl bindings, they at least list all existing methods, I don't
> know if they are on the cvs yet. Frank, thinking about this, I may want
> a cvs commit rights to update and maintain these docs.
>
> Frank mentioned somewhere that the files in cvs can be seen on the web
> but I didn't find a link on gdal.maptools.org?

Ari,

The current CVS source code (well updated at least daily)
can be found at:

  http://www.gdal.org/srctree/

On the general issue of script bindings, I find it hard to imagine
that we have the manpower and dicipline to keep several different
sets of language bindings up to date.  

Best regards,

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

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

building MrSID SDK on Linux

Bart van den Eijnden (OSGIS)
In reply to this post by Ari Jolma
Hi list,

can anybody share any of their experiences with building GDAL against a MrSID SDK on Linux (Red Hat Enterprise 3). Is it difficult, does it take a lot of time?

Is it true that GDAL has to be compiled with the same g++/gcc version as the MrSID SDK library? We are using
gcc/g++ 3.2.3-24.

Best regards,
Bart

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: building MrSID SDK on Linux

Frank Warmerdam
On 9/20/05, Bart van den Eijnden <[hidden email]> wrote:
> Hi list,
>
> can anybody share any of their experiences with building GDAL against a MrSID SDK on Linux (Red Hat Enterprise 3). Is it difficult, does it take a lot of time?
>
> Is it true that GDAL has to be compiled with the same g++/gcc version as the MrSID SDK library? We are using
> gcc/g++ 3.2.3-24.

Bart,

I am pretty sure there is a 3.2.3 compatible version of
the DSDK posted on the develop.lizardtech.com web site.
But yes, you do need a gcc for the same version of gcc
as you are using, at least roughly.  to some extent (as
Bill has noted before) you can work around some difference
by linking in more than one c++ support library but that gets
messy.

Best regards,

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

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev