Salut Michael
> Indeed, I have committed the change about one week ago.
mhm.. I have not seen them at the svn-mail list but you are right! I can
see it in the SVN History (5.May). Sorry... looks like I need to check
the mail list settings?
> I think I'll do also the second change proposed by ju
Hi Stefan,
Indeed, I have committed the change about one week ago.
I think I'll do also the second change proposed by jukko before the end
of the week as no one has reacted.
Thanks for all the improvements you have done the few last months.
Thanks also to Uwe for its new tutorial (is there any p
huhu? question again:
Are you commiting it Larry? or Michael? As you both have done the work..
Otherwise people that check the sourceforge statistics think I do all
the stuff.
However, I can do it if you are too busy :)
Stefan
Stefan Steiniger schrieb:
> great!
>
> thank you Larry and Michael.
great!
thank you Larry and Michael.
@Michael: would you do the commit?
stefan
Larry Becker wrote:
> Hi Michaël,
>
> Thanks for the testing. It sounds like this code change is ready to
> be committed. Also, thanks to your instructions, I was able to
> construct island multipolygons and te
Hi Michaël,
Thanks for the testing. It sounds like this code change is ready to be
committed. Also, thanks to your instructions, I was able to construct
island multipolygons and test reading them as shapefiles. They appear to
work, even inside CW holes.
If any Geotools or uDig people are
Hi, Larry,
I did some tests today with your new PolygonHandler.
I had no file known for the specific problem the new class is supposed
to solve, but I tried to load several files with more or less valid
geometries.
Most shapefiles have been read exactly the same way with the old code
and with
Hi, Larry
> Hi Michaël,
>
> I found another problem with the PolygonHandler routines I copied from
> geotools. It causes MultiPolygons to be created by default instead of
> simple Polygons. I restored the original code and inserted the
> modifications for clockwise holes. Now it is a much les
Hi Michaël,
I found another problem with the PolygonHandler routines I copied from
geotools. It causes MultiPolygons to be created by default instead of
simple Polygons. I restored the original code and inserted the
modifications for clockwise holes. Now it is a much less radical change.
Note
Hi Michaël,
I've attached OJ's updated PolygonHandler for your review. It is a fairly
radical change so exhaustive testing of shapefile loading is recommended.
regards,
Larry
On Fri, Apr 18, 2008 at 3:43 PM, Michaël Michaud <[EMAIL PROTECTED]>
wrote:
> Hi, Larry
>
> I'm glad if I could help, t
Hi, Larry
I'm glad if I could help, thanks again for the hard work.
It seems that you found a way to keep both correctness and performance.
If you think you can commit, I am very confident.
I'll be able to do more tests with complex polygons (but not with CW holes).
Note : you can create a MultiP
Hi Michaël,
Thank you very much for your thoughts and your patience. This is what I
am doing now:
I have replaced the shellsOverlap() method with a new findCWHoles() method.
This method uses a nested loop to return a list of all rings contained
inside any other ring. The holes are tested usi
I don't want to muddy this conversation, but you guys have triggered
my curiousity.
Michael wrote: "Polygon may have multiple outer rings..."
This is only true in the case of a polygon with holes, correct?
Michael wrote: "I think it is necessary to test inclusion of the
current ring in the
ongoi
Hi Larry,
Thanks for clarification (my english is not so good, and I often need a
detailed explanation to grasp the problem)
I think your approach is the good one as the problem we want to solve is
much more specific than the one I tried to solve in my GeoConcept parser.
Try to sum up differen
Hi Michaël,
Thanks for the advice. I may end up doing the DE-9IM matrix, but I'd like
to start with a review and critique of what I'm currently doing. To
reiterate:
The problem that I'm trying to fix is: support for polygon shells with CW
holes in PolygonHandler because ESRI allows this. With
Hi Larry,
I get a case somewhat similar with a parser I wrote for GeoConcept format.
In this format, multi-polygon come as a set of linear rings with no
special order and eventually some overlaps or other bad topology I
wanted to catch.
I decided to compute the DE-9IM matrix in a double loop
Som
Hi Stefan,
Thanks for holding my feet to the fire on this issue. I've been traveling
the last week, but I'm ready to work on it again. I'll get back to you in
the next couple of days.
thanks,
Larry
On Thu, Apr 17, 2008 at 1:46 AM, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
> Hei Larry,
>
>
Hei Larry,
as I am reading the left over emails from last week:
any news on this issue?
stefan
Larry Becker schrieb:
> It looks like the code needs more work. I'm just using it as a quick
> fix for now.
>
> thanks,
> Larry
>
> On Fri, Apr 4, 2008 at 2:22 PM, Sunburned Surveyor
> <[EMAIL PRO
It looks like the code needs more work. I'm just using it as a quick fix
for now.
thanks,
Larry
On Fri, Apr 4, 2008 at 2:22 PM, Sunburned Surveyor <
[EMAIL PROTECTED]> wrote:
> You guys are definitely over my head, but it sounds like I should hold
> off on commiting Larry's file. Is this correc
You guys are definitely over my head, but it sounds like I should hold
off on commiting Larry's file. Is this correct?
If Larry is still working on a fix I can wait until he tells me it is
ready to be commited.
The Sunburned Surveyor
On Fri, Apr 4, 2008 at 12:14 PM, Larry Becker <[EMAIL PROTECTE
Well, I have already found problems with this mod. I incorrectly assumed
that the clock-ness of the shells that were added as holes would be fixed by
later methods. That appears not to be true. Even though the mod makes the
holes appear correct, they still test bad with the QA tool. I'll have t
Martin Davis a écrit :
>Michaël Michaud wrote:
>
>
>>... about the second point, as you know SFS a no one, you may have an
>>answer to the following question :
>>why polylines may be made of lines sharing their boundaries
>>and multipolygons cannot be made of polygons sharing their edges (if
>
Michaël Michaud wrote:
>
> ... about the second point, as you know SFS a no one, you may have an
> answer to the following question :
> why polylines may be made of lines sharing their boundaries
> and multipolygons cannot be made of polygons sharing their edges (if
> that's what "shells can to
>Actually in SFS a hole can touch the shell at at most one point. Two
>shells can touch at any finite number of points.
>
>
Hey, of course, you are right.
We spent so much times to discuss this point with some co-workers that I
mixed up everything.
... about the second point, as you know SFS
Michaël Michaud wrote:
>
> I'm not sure about shapefile, but for SFS, I think that a hole cannot
> touch the exterior ring but two exterior ring can touch each other.
>
Actually in SFS a hole can touch the shell at at most one point. Two
shells can touch at any finite number of points.
Hav
Hi Larry,
It is not easy to understand the changes you did, but I tried to review
your code and have some questions :
In shellsOverlap, there is the following condition :
CGAlgorithms.isPointInRing(testPt, coordList) || (pointInList(testPt,
coordList)))
I'm not sure about shapefile, but for SF
Larry,
You wrote: " I was waiting for one of the other developers experienced
with the shapfile reader to comment on the change."
I don't think we have one. :]
If there are not objections I will commit the change today when I
commit Peppe's I18N file changes. Thank you for your work. I
apprecia
Hi Sunburned,
I believe that SkyJUMP and OpenJUMP are the same for shapefile code. It
should only be necessary to copy the file over to the OpenJUMP project. I
was waiting for one of the other developers experienced with the shapfile
reader to comment on the change.
regards,
Larry
On Fri, A
Larry,
Will we need to make mods to OpenJUMP to benefit from your
improvements? I am a little confused as to whether this is a fix you
made to a tool specific to SkyJUMP, or if we need to fix OpenJUMP's
Shapefile reader.
The Sunburned Surveyor
On Thu, Apr 3, 2008 at 2:11 PM, Larry Becker <[EMAIL
Thanks for the quick answer, Martin. I've made a mod to PolygonHandler in
SkyJUMP and committed my change. You can browse it at:
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/org/geotools/shapefile/PolygonHandler.java?view=markup
My mod begins in read() at "// quick optimization:". I used
Ugh.
Larry, I think your approach is probably what's necessary. I would
suggest NOT trying to do a JTS contains() to implement the "wholly
inside" test - it would be very slow (although the new PreparedGeometry
work would make it a lot faster - but it would still be slow).
You might consider
i am having the exact same problem with some esri generated shapefiles
from one of my sources.
eric
On Apr 3, 2008, at 11:24 AM, Larry Becker wrote:
I've found a shapefile that has what JTS thinks is a topology error
of "overlapping shells". In ESRI ArcMap it displays correctly as a
sh
I've found a shapefile that has what JTS thinks is a topology error of
"overlapping shells". In ESRI ArcMap it displays correctly as a shell
polygon with a hole, but in JUMP, it displays as overlapping polygons. It
fails the QA "Basic Topology" test. I have verified that the "hole" polygon
is no
32 matches
Mail list logo
