Paul,
Okay - is this number CVS of Geos or CVS of JTS pull?
I guess it doesn't really matter too much. I'll assume JTS 1.71 when I'm
looking at a file and compare against JTS 1.71 unless I notice its got mutant
or upper stream code in it and then look up or down a version. At least it
give
Unlike SVN, where the revision number refers to the whole repository
at once, the CVS revision numbers increment per-file.
P.
On Wed, Sep 17, 2008 at 7:10 PM, Obe, Regina <[EMAIL PROTECTED]> wrote:
> Ah okay that explains a lot why all these numbers are in the 1.1 - 1.5
> range. So I take it I c
Ah okay that explains a lot why all these numbers are in the 1.1 - 1.5 range.
So I take it I can't completely trust the 1.71 since they don't all have the
same revision number, though it seems about right from the classes I've looked
at minus the obvious diversions from the path.
-Origi
Hmm - Okay I guess I missed earlier on the version.h that gives the
GEOS_JTS_PORT constant of 1.7.1
Is it safe to assume from this that all classes are ported/verified at the same
time so I can assume all GEOS 3+ code is vintage JTS 1.7.1 unless the jtsport()
method is overridden and I can igno
No, I think you need to check more closely, as the value given there
might be the actual CVS version string, as opposed to the JTS release
version.
P.
On Wed, Sep 17, 2008 at 5:58 PM, Obe, Regina <[EMAIL PROTECTED]> wrote:
> Okay so I guess we still need the elevation thing. Can we get rid of th
Okay so I guess we still need the elevation thing. Can we get rid of the
checkwrong thing or is that still needed for 64-bit systems?
On a slightly (I like things I can understand note :)), can we update the
header about the Last Ported. Its driving me a bit crazy that the last ported
note doe
Not so much pure - I just like things that I can understand 8^)
Paul Ramsey wrote:
Z-processing was added under contract to the Metropolitan Airport
Commission, some years ago, so that intersections (in particular)
would retain interpolated Z-values that "made sense". This was
GEOS-only.
Sand
Z-processing was added under contract to the Metropolitan Airport
Commission, some years ago, so that intersections (in particular)
would retain interpolated Z-values that "made sense". This was
GEOS-only.
Sandro also did a good deal of robustness work in GEOS only, which
dealt with failures show
I can confirm - if GEOS is doing something with computing new Z-values
this is something which is NOT in JTS. I vaguely recollect that this is
something which Sandro added.
Obe, Regina wrote:
Okay I did a quick union run of a 3 d geometry in PostGIS and it
apparently does do something with th
Okay I did a quick union run of a 3 d geometry in PostGIS and it
apparently does do something with the z index
SELECT ST_AsEWKT(ST_Union(ST_MakePoint(x,y,z)))
FROM generate_series(1,5) x
CROSS JOIN generate_series(2,10) y
CROSS JOIN generate_series(1,10) z;
yields
MULTIPOINT(1 2 9
The other thing I'm noticing is that the Geometry.union() methods are
completely different between the Geos trunk and JTS (well 1.7 I'm looking at at
the moment), but I haven't looked at older JTS code or 1.9 to
see if it matches with what it claims to be JTS 1.1 port.
The Geos Geometry.Union()
Martin Davis wrote:
> The original plan for GEOS was that it would track JTS 100%. This was
> to simplify porting new functionality as it is added to JTS. However,
> at one point I think Sandro did some extra work on trying to improve
> GEOS robustness. This is probably where the checkObviouslyW
The original plan for GEOS was that it would track JTS 100%. This was
to simplify porting new functionality as it is added to JTS. However,
at one point I think Sandro did some extra work on trying to improve
GEOS robustness. This is probably where the checkObviouslyWrongResult
came from. A
Obe, Regina wrote:
> I apologize for the barrage of questions. As far as I can tell the
> OverlayOp.cpp is vintage JTS 1.7 (which I think is same as the JTS
> 1.9 for this class)
>
> except it has the additional calls of
>
> checkObviouslyWrongResult() - which most of that code looks like it
>
I apologize for the barrage of questions. As far as I can tell the
OverlayOp.cpp is vintage JTS 1.7 (which I think is same as the JTS 1.9 for this
class)
except it has the additional calls of
checkObviouslyWrongResult() - which most of that code looks like it would never
be called because of t
Obe, Regina wrote:
> Mateusz,
>
>> Are you asking about the redundant "using" directive or about use of
>> "using" directive in general?
>
> Mostly the redundant using.
Regina,
I have to correct my response.
There is no redundant use of using directive in geos_c.cpp file.
The first using (line
Obe, Regina wrote:
> Mateusz,
>
>> Are you asking about the redundant "using" directive or about use of
>> "using" directive in general?
>
> Mostly the redundant using. I wasn't sure if there was some mysterious
> class I was missing.
OK
> I assume using in C++ plays the same role as it does in
I'm still trying to understand the geos codebase and just C and C++ in
general, so forgive me if my questions seem naive.
In the geos_c.cpp (both trunk and 3.0) - starting at line 92
I see this
using geos::operation::overlay::OverlayOp;
using geos::operation::overlay::overlayOp;
I assume the on
Mateusz,
> Are you asking about the redundant "using" directive or about use of
> "using" directive in general?
Mostly the redundant using. I wasn't sure if there was some mysterious
class I was missing. I assume using in C++ plays the same role as it
does in C#.
Thanks,
Regina
Obe, Regina wrote:
> I'm still trying to understand the geos codebase and just C and C++ in
> general, so forgive me if my questions seem naive.
>
> In the geos_c.cpp (both trunk and 3.0) - starting at line 92
>
> I see this
> using geos::operation::overlay::OverlayOp;
> using geos::operation::o
I'm looking at the operation.overlay.OverlayOp in geos trunk
In the header it says
Last port: operation/overlay/OverlayOp.java rev. 1.23
But I don't believe this to be right since when I compare the
computeOverlay methods
against 1.2 and 1.3 versions of JTS codebase, it has an additional
EdgeNodi
I accidentally sent to the old address. Sorry about that.
---
I'm looking at the operation.overlay.OverlayOp in geos trunk
In the header it says
Last port: operation/overlay/OverlayOp.java rev. 1.23
But I don't believe this to be right since wh
22 matches
Mail list logo
