Logging Bad Features
Loren
I have a question about how JUMP handles invalid features read in from
a shapefile. Basically what is happening, I am using JUMP to quickly
check for self intersections, etc. using the QA tools. But it seems
that I am not catching some of them because JUMP is automatically
correcting some of the features when it loads them from the
shapefile. My question is, "Is there a way to log the invalid
features as they are read in and alert the user?"
While this is a non-issue for JUMP users, since JUMP is correcting the
errors in the shape... I am working with some people who use other
(ESRI) software and they are seeing the self-intersections.
Let me know.
Thanks,
Loren Slater
Michaël Michaud
As far as I can remember, shapefile reader do not perform topology
correction at read time, except that it may be able to hold rings with a
wrong orientation (rings which have orientation of a hole but which are
not included in another ring).
Have you got a test case (a shape whose geometry is "corrected" by OpenJUMP)
Micha�l
Loren a �crit :
Loren Slater
Hi Loren,
As far as I can remember, shapefile reader do not perform topology correction at read time, except that it may be able to hold rings with a wrong orientation (rings which have orientation of a hole but which are not included in another ring).
Have you got a test case (a shape whose geometry is "corrected" by OpenJUMP)
Michaël
Loren a écrit :
Michaël Michaud
You're right,
Here is the commented part of the code dealing with three points ring :
//REVISIT: polyons with only 1 or 2 points are not polygons -
geometryFactory will bomb so we skip if we find one.
if(points.length == 0 || points.length > 3) {
LinearRing ring = geometryFactory.createLinearRing(points);
I'm not sure what is the best approach to solve your problem. I see 3
solutions.
1 - quick and dirty : do a print in the console each time a geometry is
skipped
2 - more difficult : try to log the fact that a part of the geometry has
been skipped in OpenJUMP. Not that easy, because currently,
ShapefileReader do not know OpenJump environment.
3 - quite easy : return a GeometryCollection where the three points ring
is represented as a LineString (drawback is that most people will have
to add a step to clean the layer as they do not want those dirty
geometries)
Let's see what others say
Micha�l
Loren Slater a �crit :
> Hi,
>
> Attached is a shapefile with examples. Each feature in that file has
> at least one exterior ring that only has 2 points (invalid). These
> are being displayed in other software, but not in OJ.
>
> -Loren
>
> 2010/3/9 Micha�l Michaud <michael...@free.fr
> <mailto:michael...@free.fr>>
>
> Hi Loren,
>
> As far as I can remember, shapefile reader do not perform topology
> correction at read time, except that it may be able to hold rings
> with a wrong orientation (rings which have orientation of a hole
> but which are not included in another ring).
> Have you got a test case (a shape whose geometry is "corrected" by
> OpenJUMP)
>
> Micha�l
>
> Loren a �crit :
>
Larry Becker
Larry
Hi Loren,
You're right,
Here is the commented part of the code dealing with three points ring :
//REVISIT: polyons with only 1 or 2 points are not polygons - geometryFactory will bomb so we skip if we find one.
if(points.length == 0 || points.length > 3) {
LinearRing ring = geometryFactory.createLinearRing(points);
I'm not sure what is the best approach to solve your problem. I see 3 solutions.
1 - quick and dirty : do a print in the console each time a geometry is skipped
2 - more difficult : try to log the fact that a part of the geometry has been skipped in OpenJUMP. Not that easy, because currently, ShapefileReader do not know OpenJump environment.
3 - quite easy : return a GeometryCollection where the three points ring is represented as a LineString (drawback is that most people will have to add a step to clean the layer as they do not want those dirty geometries)
Let's see what others say
Michaël
Loren Slater a écrit :
Hi,
Attached is a shapefile with examples. Each feature in that file has at least one exterior ring that only has 2 points (invalid). These are being displayed in other software, but not in OJ.
-Loren
2010/3/9 Michaël Michaud <michael...@free.fr <mailto:michael...@free.fr>>
Hi Loren,
As far as I can remember, shapefile reader do not perform topology
correction at read time, except that it may be able to hold rings
with a wrong orientation (rings which have orientation of a hole
but which are not included in another ring).
Have you got a test case (a shape whose geometry is "corrected" by
OpenJUMP)
Michaël
Loren a écrit :
Hi Everyone,
I have a question about how JUMP handles invalid features read
in from
a shapefile. Basically what is happening, I am using JUMP to
quickly
check for self intersections, etc. using the QA tools. But it
seems
that I am not catching some of them because JUMP is automatically
correcting some of the features when it loads them from the
shapefile. My question is, "Is there a way to log the invalid
features as they are read in and alert the user?"
While this is a non-issue for JUMP users, since JUMP is
correcting the
errors in the shape... I am working with some people who use
other
(ESRI) software and they are seeing the self-intersections.
Let me know.
Thanks,
Loren Slater
--
Larry Becker
Integrated Systems Analysts, Inc.
Jukka Rahkonen
I have seen such data in OpenStreetMap coastline shapefiles. They can be
loaded into PostGIS but three point inner rings can make problems later.
PostGIS function IsValid finds them.
I would have tried if the same could be done with Spatialite which also
has IsValid function, but because you sent only .shp part of the shapefile
I could not load data into Spatialite. Most programs are not as clever as
OpenJUMP with shapefiles
Spatialite way, if it works, could be rather simple to use. I can test it
if you resent the data as a complete shapefile.
-Jukka Rahkonen-
> Hi,
>
> Attached is a shapefile with examples. Each feature in that file has at
> least one exterior ring that only has 2 points (invalid). These are being
> displayed in other software, but not in OJ.
>
> -Loren
>
> 2010/3/9 Micha�l Michaud <michael...@free.fr>
>
>> Hi Loren,
>>
>> As far as I can remember, shapefile reader do not perform topology
>> correction at read time, except that it may be able to hold rings with a
>> wrong orientation (rings which have orientation of a hole but which are
>> not
>> included in another ring).
>> Have you got a test case (a shape whose geometry is "corrected" by
>> OpenJUMP)
>>
>> Micha�l
>>
>> Loren a �crit :
>>
Loren Slater
Hi,
I have seen such data in OpenStreetMap coastline shapefiles. They can be
loaded into PostGIS but three point inner rings can make problems later.
PostGIS function IsValid finds them.
I would have tried if the same could be done with Spatialite which also
has IsValid function, but because you sent only .shp part of the shapefile
I could not load data into Spatialite. Most programs are not as clever as
OpenJUMP with shapefiles
Spatialite way, if it works, could be rather simple to use. I can test it
if you resent the data as a complete shapefile.
-Jukka Rahkonen-
> Hi,
>
> Attached is a shapefile with examples. Each feature in that file has at
> least one exterior ring that only has 2 points (invalid). These are being
> displayed in other software, but not in OJ.
>
> -Loren
>
> 2010/3/9 Michaël Michaud <michael...@free.fr>
>
>> Hi Loren,
>>
>> As far as I can remember, shapefile reader do not perform topology
>> correction at read time, except that it may be able to hold rings with a
>> wrong orientation (rings which have orientation of a hole but which are
>> not
>> included in another ring).
>> Have you got a test case (a shape whose geometry is "corrected" by
>> OpenJUMP)
>>
>> Michaël
>>
>> Loren a écrit :
Jukka Rahkonen
I imported your shapefile into Spatialite database with Spatialite-GUI tool.
Spatialite takes all shapes as they are with all the errors. I selected
first multipolygon as WKT and tried to add that into OpenJUMP but it does
not take it. It gives
java.lang.IllegalArgumentException: Invalid number of points in LinearRing
(found 3 - must be 0 or >= 4)
It looks like it is impossible to read these three coordinate pair rings
(from point A to B and back to A) into OpenJUMP. On the other hand it is
good but the side effect is that it is impossible to repair those errors
with OJ.
Spatialite function IsValid gives correct result and tells that the
geometry in not valid. It does not tell what the matter is, where it is
and how to repair it. I do not know if there are some geometry correction
tools for Spatialite.
Perhaps there should be an option to import also erraneous rings into
OpenJUMP so that they could be corrected. Or would these A-B-A polygons
just make JTS to crach or something?
-Jukka-
Pasted things follow:
Faulty multipolygon as WKT, the last part is A-B-A
MULTIPOLYGON(((-71.53372 42.52755, -71.53138 42.5204, -71.53042 42.52,
-71.52972 42.51976, -71.53185 42.51578, -71.5325 42.51456, -71.53386
42.51373, -71.53481 42.51316, -71.54365 42.50011, -71.54728 42.49445,
-71.55039 42.48964, -71.55069 42.48917, -71.55077 42.48905, -71.55266
42.4863, -71.55492 42.48279, -71.56143 42.48973, -71.56163 42.48977,
-71.56268 42.49435, -71.56285 42.49446, -71.56278 42.49456, -71.56267
42.49472, -71.56296 42.49478, -71.56303 42.49466, -71.56531 42.49346,
-71.5689 42.49331, -71.56947 42.49533, -71.56961 42.49547, -71.56974
42.49559, -71.56968 42.49575, -71.56968 42.49571, -71.5696 42.49572,
-71.56937 42.49572, -71.56923 42.49587, -71.56871 42.49642, -71.56861
42.49657, -71.56857 42.49663, -71.56839 42.49704, -71.5647 42.49734,
-71.56627 42.5008, -71.56813 42.49788, -71.56884 42.49791, -71.56887
42.49791, -71.5693 42.49794, -71.57109 42.49818, -71.57192 42.49819,
-71.57275 42.49805, -71.57295 42.49802, -71.5739 42.49786, -71.57444
42.49786, -71.57474 42.49785, -71.57489 42.49799, -71.57665 42.49861,
-71.57671 42.49841, -71.57732 42.4964, -71.57761 42.49659, -71.57758
42.49679, -71.5776 42.49856, -71.57775 42.49869, -71.57772 42.49872,
-71.57759 42.49887, -71.57746 42.50046, -71.57766 42.50041, -71.57785
42.50038, -71.58111 42.50047, -71.58131 42.50052, -71.58295 42.50091,
-71.58303 42.50086, -71.58314 42.50095, -71.58355 42.50149, -71.58361
42.50155, -71.58389 42.50167, -71.58399 42.50155, -71.58401 42.50152,
-71.58403 42.50158, -71.58399 42.50162, -71.58409 42.50163, -71.58405
42.50177, -71.58416 42.50171, -71.58418 42.50169, -71.58431 42.50167,
-71.58423 42.50183, -71.58438 42.50228, -71.58458 42.50231, -71.58473
42.50074, -71.58477 42.50054, -71.58494 42.50072, -71.58502 42.50082,
-71.58513 42.50106, -71.58592 42.50197, -71.58471 42.50255, -71.58467
42.5024, -71.58461 42.50241, -71.58443 42.50245, -71.58424 42.50249,
-71.58429 42.50355, -71.58449 42.50359, -71.58468 42.50362, -71.58483
42.50569, -71.5847 42.50584, -71.58468 42.5062, -71.58483 42.50634,
-71.58682 42.5103, -71.58255 42.51489, -71.58255 42.51509, -71.58255
42.51529, -71.58679 42.5181, -71.58306 42.52022, -71.58304 42.52028,
-71.58295 42.52054, -71.58302 42.52065, -71.58649 42.52391, -71.58647
42.52411, -71.58445 42.52403, -71.58174 42.52388, -71.58167 42.52383,
-71.56699 42.52274, -71.56475 42.52258, -71.56286 42.52254, -71.56107
42.52265, -71.55998 42.52277, -71.55899 42.52293, -71.55581 42.52354,
-71.55299 42.52404, -71.55295 42.52407, -71.55289 42.52406, -71.55286
42.52409, -71.5528 42.52408, -71.55276 42.52411, -71.5527 42.5241,
-71.55266 42.52413, -71.5526 42.52412, -71.55256 42.52414, -71.5525
42.52413, -71.55246 42.52416, -71.5524 42.52415, -71.55236 42.52418,
-71.5523 42.52417, -71.55227 42.5242, -71.55221 42.52419, -71.55217
42.52422, -71.55211 42.52421, -71.55207 42.52423, -71.55201 42.52422,
-71.55197 42.52425, -71.55191 42.52424, -71.55187 42.52427, -71.55181
42.52426, -71.55177 42.52429, -71.55171 42.52428, -71.55168 42.52431,
-71.55162 42.5243, -71.55158 42.52433, -71.55152 42.52432, -71.55148
42.52434, -71.55142 42.52433, -71.55138 42.52436, -71.55132 42.52435,
-71.55128 42.52438, -71.55122 42.52437, -71.55118 42.5244, -71.55112
42.52439, -71.55109 42.52442, -71.55103 42.52441, -71.55099 42.52443,
-71.55095 42.52437, -71.5509 42.52427, -71.55089 42.52438, -71.55089
42.52441, -71.55089 42.52445, -71.55083 42.52445, -71.55073 42.52444,
-71.53677 42.52702, -71.53676 42.52704, -71.53676 42.52708, -71.53671
42.5271, -71.53667 42.52704, -71.53378 42.5276, -71.53374 42.52761,
-71.53372 42.52755), (-71.58192 42.52216, -71.58234 42.52219, -71.58239
42.52204, -71.5823 42.52186, -71.58176 42.52204, -71.58192 42.52216),
(-71.56704 42.51614, -71.56206 42.5163, -71.56188 42.51638, -71.56145
42.517, -71.5613 42.51687, -71.56115 42.51673, -71.56039 42.51314,
-71.56036 42.51294, -71.55378 42.51224, -71.54927 42.51638, -71.54802
42.52096, -71.551 42.52428, -71.55106 42.5243, -71.55111 42.52432,
-71.56112 42.52015, -71.56686 42.52258, -71.56695 42.52269, -71.56708
42.52251, -71.56716 42.5163, -71.56704 42.51614), (-71.57626 42.50783,
-71.57611 42.5077, -71.57604 42.50778, -71.57609 42.50798, -71.57612
42.50808, -71.5766 42.50837, -71.57697 42.50847, -71.57857 42.50858,
-71.57893 42.50856, -71.57912 42.50851, -71.57938 42.50726, -71.57938
42.50706, -71.5763 42.50786, -71.57626 42.50783), (-71.55413 42.50389,
-71.55424 42.50396, -71.55816 42.49948, -71.55873 42.49953, -71.55882
42.49962, -71.55894 42.49974, -71.56029 42.50017, -71.56049 42.50017,
-71.56071 42.49988, -71.56055 42.49999, -71.56049 42.49987, -71.55991
42.49978, -71.55982 42.49976, -71.55963 42.4997, -71.55921 42.49951,
-71.55916 42.49937, -71.55881 42.49924, -71.55866 42.49911, -71.55854
42.49893, -71.55857 42.49879, -71.55872 42.49854, -71.55875 42.49806,
-71.55888 42.49791, -71.55885 42.49765, -71.55866 42.49772, -71.55845
42.49781, -71.55826 42.49784, -71.54928 42.50031, -71.55413 42.50389),
(-71.5551 42.49189, -71.55492 42.49198, -71.55284 42.49682, -71.55284
42.49702, -71.55755 42.49446, -71.55529 42.49181, -71.5551 42.49189)),
((-71.56026 42.47448, -71.56011 42.47436, -71.5597 42.47417, -71.56009
42.47413, -71.5602 42.47408, -71.56026 42.47404, -71.56031 42.47419,
-71.56034 42.47429, -71.5604 42.47448, -71.56018 42.47461, -71.56026
42.47448)), ((-71.534 42.52831, -71.53395 42.52819, -71.53666 42.52717,
-71.53676 42.52723, -71.53466 42.53032, -71.534 42.52831)), ((-71.58201
42.52434, -71.58169 42.52442, -71.58157 42.52437, -71.58138 42.5243,
-71.58168 42.52392, -71.58172 42.52393, -71.5819 42.52417, -71.58201
42.52434)), ((-71.6132 42.4943, -71.61265 42.49528, -71.61248 42.4954,
-71.61265 42.49446, -71.6132 42.4943)), ((-71.59197 42.51137, -71.59212
42.51125, -71.59258 42.5118, -71.59242 42.51192, -71.59135 42.51279,
-71.59139 42.51259, -71.59181 42.5115, -71.59197 42.51137)), ((-71.59115
42.50067, -71.59117 42.50047, -71.5946 42.50066, -71.59458 42.50086,
-71.5949 42.50103, -71.59496 42.50111, -71.59497 42.50104, -71.59501
42.50104, -71.595 42.50114, -71.59485 42.5012, -71.59433 42.5014,
-71.59348 42.50188, -71.59285 42.50215, -71.59267 42.50222, -71.59113
42.50087, -71.59115 42.50067)), ((-71.58915 42.50858, -71.58895 42.50856,
-71.58828 42.50827, -71.58843 42.50814, -71.58813 42.5047, -71.58857
42.50448, -71.5893 42.50478, -71.58958 42.5073, -71.58926 42.5086,
-71.58915 42.50858)), ((-71.64033 42.48553, -71.64023 42.4857, -71.62386
42.5073, -71.62372 42.50745, -71.62353 42.50742, -71.6138 42.49406,
-71.61397 42.49396, -71.61408 42.4939, -71.61516 42.49313, -71.6158
42.49274, -71.61713 42.49201, -71.59977 42.49137, -71.59958 42.49129,
-71.59965 42.49111, -71.60096 42.48159, -71.61831 42.48486, -71.61843
42.48502, -71.61918 42.48774, -71.61936 42.48782, -71.61954 42.48791,
-71.63109 42.48689, -71.63127 42.48681, -71.63711 42.48492, -71.64033
42.48553), (-71.5838 42.50088, -71.58384 42.50096, -71.5838 42.50088),
(-71.58401 42.50152, -71.58405 42.50148, -71.58401 42.50152)))
OpenJUMP error message:
java.sql.SQLException: Invalid number of points in LinearRing (found 3 -
must be 0 or >= 4)
at
org.freevoice.jumpdbqueryextension.spatialite.JumpSpatialiteDbQuery.getAttributeValueFromResults(JumpSpatialiteDbQuery.java:359)
at
org.freevoice.jumpdbqueryextension.AbstractJumpDBQuery.addFeatureToCollection(AbstractJumpDBQuery.java:122)
at
org.freevoice.jumpdbqueryextension.spatialite.JumpSpatialiteDbQuery.getCollection(JumpSpatialiteDbQuery.java:308)
at
org.freevoice.jumpdbqueryextension.JumpDbQueryPlugin.execute(JumpDbQueryPlugin.java:80)
at
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:130)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.AbstractButton.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(Unknown
Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
>> > 2010/3/9 Micha�l Michaud <michael...@free.fr>
>> >
>> >> Hi Loren,
>> >>
>> >> As far as I can remember, shapefile reader do not perform topology
>> >> correction at read time, except that it may be able to hold rings
>> with a
>> >> wrong orientation (rings which have orientation of a hole but which
>> are
>> >> not
>> >> included in another ring).
>> >> Have you got a test case (a shape whose geometry is "corrected" by
>> >> OpenJUMP)
>> >>
>> >> Micha�l
>> >>
>> >> Loren a �crit :
>> >>
Stefan Steiniger
sorry for responding so late
Micha�l Michaud wrote:
> Hi Loren,
>
> I'm not sure what is the best approach to solve your problem. I see 3
> solutions.
> 1 - quick and dirty : do a print in the console each time a geometry is
> skipped
which would require to say what shape (ID) has been skipped and maybe
the user wants to see this one
> 2 - more difficult : try to log the fact that a part of the geometry has
> been skipped in OpenJUMP. Not that easy, because currently,
> ShapefileReader do not know OpenJump environment.
mhm.. the reader doesn't know.. well then I would go with 3, but:
> 3 - quite easy : return a GeometryCollection where the three points ring
> is represented as a LineString (drawback is that most people will have
> to add a step to clean the layer as they do not want those dirty
> geometries)
can we create LinearRings with 2 points and then in a later step of the
file loader filter those 2-point linestrings out, and create a new layer
with those. Otherwise discarding such shapes is better then linestrings
in the dataset (but here we need a message of course).
my 2 cents
stefan
Larry Becker
Larry
Hei,
sorry for responding so late
Larry Becker
I opened your latest attachment in ArcMap 9.2 and it didn't report any errors. Visually the last multipolygon looked the same in ESRI as it did in OpenJump.
regards,
Larry
Loren Slater
Hi Larry,
I am able to reproduce the issue using ArcView 9.2 (Build 1500) using the previously posted files. Running the check geometry tool reports self intersections and the invalid shapes are visible. I am attaching a point file that contains the locations of the invalid areas. I know once upon a time I installed a patch to ArcView, not sure if that might be making a difference. Hope this helps.
Thanks,
Loren
On Mar 11, 2010 2:14 PM, "Larry Becker" <becker...@gmail.com> wrote:
Loren,
I opened your latest attachment in ArcMap 9.2 and it didn't report any errors. Visually the last multipolygon looked the same in ESRI as it did in OpenJump.
regards,
Larry
On Wed, Mar 10, 2010 at 11:02 AM, Larry Becker <becker...@gmail.com> wrote:
>
> Isn't one of th...
Larry Becker
Retracing your steps in ArcGIS with the check geometry tool turns out to be beyond my ESRI skill set, but I get your point.
3 - quite easy : return a GeometryCollection where the three points ring is represented as a LineString (drawback is that most people will have to add a step to clean the layer as they do not want those dirty geometries)can we create LinearRings with 2 points and then in a later step of the file loader filter those 2-point linestrings out, and create a new layer with those. Otherwise discarding such shapes is better then linestrings in the dataset (but here we need a message of course).
I agree with Stefan that we should break the linestrings out into their own layer. If Michaël can come up with a way to return status from the shapefile reader, I'll volunteer to break out the linestrings.
regards,
Larry
Michaël Michaud
> Assuming Micha�l is volunteering to implement his solution 3 (it
> doesn't sound easy to me), we seem to be faced with two not-so-good
> alternatives: skip invalid data (as we do now) that we would like the
> opportunity to fix, or convert to linestrings in a polygon shapefile
> dataset. The linestring option favors advanced users, and what we do
> now is better for novices.
I think that returning a GeometryCollection instead of a Polygon to
handle these cases is quite easy (maybe I missed something). But it may
be a pain in the other way (OpenJUMP to shapefile) as the user will not
be able to save its shapefile without preprocessing it (separating
Polygons from LineStrings).
I agree this is not very user friendly.
On the other hand :
- in some situation, it may be more useful to know your input data is
not correct than to get only the correct ones (I'm quite often in this case)
- OpenJUMP has nice tools to deal with GeometryCollections and to
separate polygonal geometries from lineal ones.
> I agree with Stefan that we should break the linestrings out into
> their own layer. If Micha�l can come up with a way to return status
> from the shapefile reader, I'll volunteer to break out the linestrings.
This may be more difficult as it does not folow the simple schema one
source file / one layer. I'll think a bit more about this problem.
Anyway, I'll not do the change without making sure most of you agree.
Micha�l
>
> regards,
> Larry
>
> On Thu, Mar 11, 2010 at 2:07 PM, Loren Slater <loren....@gmail.com
> <mailto:loren....@gmail.com>> wrote:
>
> Hi Larry,
>
> I am able to reproduce the issue using ArcView 9.2 (Build 1500)
> using the previously posted files. Running the check geometry
> tool reports self intersections and the invalid shapes are
> visible. I am attaching a point file that contains the locations
> of the invalid areas. I know once upon a time I installed a patch
> to ArcView, not sure if that might be making a difference. Hope
> this helps.
>
> Thanks,
>
> Loren
>
>> On Mar 11, 2010 2:14 PM, "Larry Becker" <becker...@gmail.com
Larry Becker
@Michaël, do you think it would be possible to just return the bad ring as a separate linestring instead of a part of a geometery collection?
Larry
Hi,
Assuming Michaël is volunteering to implement his solution 3 (it doesn't sound easy to me), we seem to be faced with two not-so-good alternatives: skip invalid data (as we do now) that we would like the opportunity to fix, or convert to linestrings in a polygon shapefile dataset. The linestring option favors advanced users, and what we do now is better for novices.
I think that returning a GeometryCollection instead of a Polygon to handle these cases is quite easy (maybe I missed something). But it may be a pain in the other way (OpenJUMP to shapefile) as the user will not be able to save its shapefile without preprocessing it (separating Polygons from LineStrings).
I agree this is not very user friendly.
On the other hand :
- in some situation, it may be more useful to know your input data is not correct than to get only the correct ones (I'm quite often in this case)
- OpenJUMP has nice tools to deal with GeometryCollections and to separate polygonal geometries from lineal ones.
I agree with Stefan that we should break the linestrings out into their own layer. If Michaël can come up with a way to return status from the shapefile reader, I'll volunteer to break out the linestrings.
This may be more difficult as it does not folow the simple schema one source file / one layer. I'll think a bit more about this problem.
Anyway, I'll not do the change without making sure most of you agree.
Michaël
Michaël Michaud
> I did some tests with Edit->Extract->Extract Layers by Geometry Type,
> and unfortunately it doesn't handle Geometry Collections properly.
> It would have been an automated way to extract the bad linestrings.
> That could be fixed, but...
work properly.
Another bug is that you can't explode a GeometryCollection. At least I
could not. Instead, I get the following exception :
java.lang.NullPointerException
at
com.vividsolutions.jts.operation.valid.IsValidOp.isValid(IsValidOp.java:62)
at com.vividsolutions.jts.geom.Point.isValid(Point.java:117)
at
com.vividsolutions.jump.workbench.ui.EditTransaction.proposedGeometriesValid(EditTransaction.java:315)
at
com.vividsolutions.jump.workbench.ui.EditTransaction.commit(EditTransaction.java:256)
at
com.vividsolutions.jump.workbench.ui.plugin.ExplodeSelectedFeaturesPlugIn.execute(ExplodeSelectedFeaturesPlugIn.java:66)
at
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:130)
Here is another quite interesting solution : Tools > Edit Geometry >
Geometric functions > Polygonize : It gives nearly what we are
interested in (Polygons included in the GeometryCollection), but
unfortunately, resulting MultiPolygons are tagged as
"GeometryCollection" which may be a problem to export to Shapefile.
I thing these three things are bug and should be fix (with a higher
priority compared to bad shapefile reading problem)
> @Micha�l, do you think it would be possible to just return the bad
> ring as a separate linestring instead of a part of a geometery collection?
Currently Shapefile returns a big GeometryCollection made of all
individual geometries of the file and ShapefileReader associate each
getGeometryN to a dbf record.
This is probably possible to do what you suggest, just adding dirty
rings at the end, without attribute and without reference to the
original Shape (not sure I like it however).
May be it is also possible to keep dirty Polygons as GeometryCollection
in the org....Shapefile class and to process those Geometries (separate
Polygons from LineStrings) in the com....ShapefileReader class (so that
attributes can be kept).
On the other hand, adding dirty LinearRing to another Layer seems more
difficult to me.
Micha�l
>
> Larry
> 2010/3/11 Micha�l Michaud <michael...@free.fr
> <mailto:michael...@free.fr>>
>
> Hi,
>
>
> Assuming Micha�l is volunteering to implement his solution 3
> (it doesn't sound easy to me), we seem to be faced with two
> not-so-good alternatives: skip invalid data (as we do now)
> that we would like the opportunity to fix, or convert to
> linestrings in a polygon shapefile dataset. The linestring
> option favors advanced users, and what we do now is better for
> novices.
>
> I think that returning a GeometryCollection instead of a Polygon
> to handle these cases is quite easy (maybe I missed something).
> But it may be a pain in the other way (OpenJUMP to shapefile) as
> the user will not be able to save its shapefile without
> preprocessing it (separating Polygons from LineStrings).
> I agree this is not very user friendly.
> On the other hand :
> - in some situation, it may be more useful to know your input data
> is not correct than to get only the correct ones (I'm quite often
> in this case)
> - OpenJUMP has nice tools to deal with GeometryCollections and to
> separate polygonal geometries from lineal ones.
>
> I agree with Stefan that we should break the linestrings out
> into their own layer. If Micha�l can come up with a way to
> return status from the shapefile reader, I'll volunteer to
> break out the linestrings.
>
> This may be more difficult as it does not folow the simple schema
> one source file / one layer. I'll think a bit more about this problem.
> Anyway, I'll not do the change without making sure most of you agree.
>
> Micha�l
>
>
> regards,
> Larry
>
>
> On Thu, Mar 11, 2010 at 2:07 PM, Loren Slater
> <loren....@gmail.com <mailto:loren....@gmail.com>
> <mailto:loren....@gmail.com
> <mailto:loren....@gmail.com>>> wrote:
>
> Hi Larry,
>
> I am able to reproduce the issue using ArcView 9.2 (Build 1500)
> using the previously posted files. Running the check geometry
> tool reports self intersections and the invalid shapes are
> visible. I am attaching a point file that contains the
> locations
> of the invalid areas. I know once upon a time I installed
> a patch
> to ArcView, not sure if that might be making a difference.
> Hope
> this helps.
>
> Thanks,
>
> Loren
>
> On Mar 11, 2010 2:14 PM, "Larry Becker"
> <becker...@gmail.com <mailto:becker...@gmail.com>
> <mailto:becker...@gmail.com
> <mailto:becker...@gmail.com>>> wrote:
>
> Loren,
>
> I opened your latest attachment in ArcMap 9.2 and it
> didn't
> report any errors. Visually the last multipolygon
> looked the
> same in ESRI as it did in OpenJump.
>
> regards,
> Larry
>
>
>
> On Wed, Mar 10, 2010 at 11:02 AM, Larry Becker
> <becker...@gmail.com <mailto:becker...@gmail.com>
> <mailto:becker...@gmail.com
Larry Becker
I thing these three things are bug and should be fix (with a higher priority compared to bad shapefile reading problem)
I'm guessing that the bug with exploding a geometry collection was caused by an invalid ring since it works for "normal" cases.
regards,
Larry
Hi Larry,You're right, Edit->Extract->Extract Layers by Geometry Type does not work properly.
I did some tests with Edit->Extract->Extract Layers by Geometry Type, and unfortunately it doesn't handle Geometry Collections properly. It would have been an automated way to extract the bad linestrings. That could be fixed, but...
Another bug is that you can't explode a GeometryCollection. At least I could not. Instead, I get the following exception :
java.lang.NullPointerException
at com.vividsolutions.jts.operation.valid.IsValidOp.isValid(IsValidOp.java:62)
at com.vividsolutions.jts.geom.Point.isValid(Point.java:117)
at com.vividsolutions.jump.workbench.ui.EditTransaction.proposedGeometriesValid(EditTransaction.java:315)
at com.vividsolutions.jump.workbench.ui.EditTransaction.commit(EditTransaction.java:256)
at com.vividsolutions.jump.workbench.ui.plugin.ExplodeSelectedFeaturesPlugIn.execute(ExplodeSelectedFeaturesPlugIn.java:66)Here is another quite interesting solution : Tools > Edit Geometry > Geometric functions > Polygonize : It gives nearly what we are interested in (Polygons included in the GeometryCollection), but unfortunately, resulting MultiPolygons are tagged as "GeometryCollection" which may be a problem to export to Shapefile.
at com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:130)
I thing these three things are bug and should be fix (with a higher priority compared to bad shapefile reading problem)
@Michaël, do you think it would be possible to just return the bad ring as a separate linestring instead of a part of a geometery collection?
Currently Shapefile returns a big GeometryCollection made of all individual geometries of the file and ShapefileReader associate each getGeometryN to a dbf record.
This is probably possible to do what you suggest, just adding dirty rings at the end, without attribute and without reference to the original Shape (not sure I like it however).
May be it is also possible to keep dirty Polygons as GeometryCollection in the org....Shapefile class and to process those Geometries (separate Polygons from LineStrings) in the com....ShapefileReader class (so that attributes can be kept).
On the other hand, adding dirty LinearRing to another Layer seems more difficult to me.
Michaël
Larry
2010/3/11 Michaël Michaud <michael...@free.fr <mailto:michael...@free.fr>>
Hi,
Assuming Michaël is volunteering to implement his solution 3
(it doesn't sound easy to me), we seem to be faced with two
not-so-good alternatives: skip invalid data (as we do now)
that we would like the opportunity to fix, or convert to
linestrings in a polygon shapefile dataset. The linestring
option favors advanced users, and what we do now is better for
novices.
I think that returning a GeometryCollection instead of a Polygon
to handle these cases is quite easy (maybe I missed something).
But it may be a pain in the other way (OpenJUMP to shapefile) as
the user will not be able to save its shapefile without
preprocessing it (separating Polygons from LineStrings).
I agree this is not very user friendly.
On the other hand :
- in some situation, it may be more useful to know your input data
is not correct than to get only the correct ones (I'm quite often
in this case)
- OpenJUMP has nice tools to deal with GeometryCollections and to
separate polygonal geometries from lineal ones.
I agree with Stefan that we should break the linestrings out
into their own layer. If Michaël can come up with a way to
return status from the shapefile reader, I'll volunteer to
break out the linestrings.
This may be more difficult as it does not folow the simple schema
one source file / one layer. I'll think a bit more about this problem.
Anyway, I'll not do the change without making sure most of you agree.
Michaël
Michaël Michaud
>
> I thing these three things are bug and should be fix (with a
> higher priority compared to bad shapefile reading problem)
>
>
> Ok, I'll take care of the Extract Layers by Geometry Type bug. I
> guess correct behavior is to split the mixed geometry types into
> separate geometry collections (if more than one of a type) and
> replicate the attributes?
>
> I'm guessing that the bug with exploding a geometry collection was
> caused by an invalid ring since it works for "normal" cases.
from valid Geometries with the Combine features command.
Could you make it work for a "normal" GeometryCollection ?
Micha�l
>
> regards,
> Larry
>
>
> 2010/3/12 Micha�l Michaud <michael...@free.fr
> <mailto:michael...@free.fr>>
> @Micha�l, do you think it would be possible to just return the
> bad ring as a separate linestring instead of a part of a
> geometery collection?
>
> Currently Shapefile returns a big GeometryCollection made of all
> individual geometries of the file and ShapefileReader associate
> each getGeometryN to a dbf record.
> This is probably possible to do what you suggest, just adding
> dirty rings at the end, without attribute and without reference to
> the original Shape (not sure I like it however).
> May be it is also possible to keep dirty Polygons as
> GeometryCollection in the org....Shapefile class and to process
> those Geometries (separate Polygons from LineStrings) in the
> com....ShapefileReader class (so that attributes can be kept).
> On the other hand, adding dirty LinearRing to another Layer seems
> more difficult to me.
>
> Micha�l
>
>
> Larry
> 2010/3/11 Micha�l Michaud <michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>>
>
>
> Hi,
>
>
> Assuming Micha�l is volunteering to implement his
> into their own layer. If Micha�l can come up with a way to
> return status from the shapefile reader, I'll volunteer to
> break out the linestrings.
>
> This may be more difficult as it does not folow the simple
> schema
> one source file / one layer. I'll think a bit more about
> this problem.
> Anyway, I'll not do the change without making sure most of
> you agree.
>
> Micha�l
Larry Becker
Could you make it work for a "normal" GeometryCollection ?
Larry
No, unfortunately, I get it from a GeometryCollection built in OpenJUMP from valid Geometries with the Combine features command.
I thing these three things are bug and should be fix (with a
higher priority compared to bad shapefile reading problem)
Ok, I'll take care of the Extract Layers by Geometry Type bug. I guess correct behavior is to split the mixed geometry types into separate geometry collections (if more than one of a type) and replicate the attributes?
I'm guessing that the bug with exploding a geometry collection was caused by an invalid ring since it works for "normal" cases.
Could you make it work for a "normal" GeometryCollection ?
Michaël
regards,
Larry
2010/3/12 Michaël Michaud <michael...@free.fr <mailto:michael...@free.fr>>
@Michaël, do you think it would be possible to just return the
bad ring as a separate linestring instead of a part of a
geometery collection?
Currently Shapefile returns a big GeometryCollection made of all
individual geometries of the file and ShapefileReader associate
each getGeometryN to a dbf record.
This is probably possible to do what you suggest, just adding
dirty rings at the end, without attribute and without reference to
the original Shape (not sure I like it however).
May be it is also possible to keep dirty Polygons as
GeometryCollection in the org....Shapefile class and to process
those Geometries (separate Polygons from LineStrings) in the
com....ShapefileReader class (so that attributes can be kept).
On the other hand, adding dirty LinearRing to another Layer seems
more difficult to me.
Assuming Michaël is volunteering to implement his
into their own layer. If Michaël can come up with a way to
return status from the shapefile reader, I'll volunteer to
break out the linestrings.
This may be more difficult as it does not folow the simple
schema
one source file / one layer. I'll think a bit more about
this problem.
Anyway, I'll not do the change without making sure most of
you agree.
Michaël
Larry Becker
Larry Becker
Michaël Michaud
in EditTransaction.deleteFeature method.
Fixed in the svn repository (replaced by empty GeometryCollection)
Micha�l
>
> On Fri, Mar 12, 2010 at 5:09 PM, Larry Becker <becker...@gmail.com
> <mailto:becker...@gmail.com>> wrote:
>
> Ah, I duplicated your problem with the latest code from SVN. So
> it is a recent change...
>
>
> On Fri, Mar 12, 2010 at 5:02 PM, Larry Becker
> <becker...@gmail.com <mailto:becker...@gmail.com>> wrote:
>
> Could you make it work for a "normal" GeometryCollection ?
>
>
> Yes. I drew a few rectangles, linestrings, and points, then
> combined them and successfully exploded them. OJ 1.3.1.
>
>
> Larry
> 2010/3/12 Micha�l Michaud <michael...@free.fr
> <mailto:michael...@free.fr>>
>
> Larry Becker a �crit :
>
>
> I thing these three things are bug and should be
> fix (with a
> higher priority compared to bad shapefile reading
> problem)
>
>
> Ok, I'll take care of the Extract Layers by Geometry
> Type bug. I guess correct behavior is to split the
> mixed geometry types into separate geometry
> collections (if more than one of a type) and replicate
> the attributes?
>
> I'm guessing that the bug with exploding a geometry
> collection was caused by an invalid ring since it
> works for "normal" cases.
>
> No, unfortunately, I get it from a GeometryCollection
> built in OpenJUMP from valid Geometries with the Combine
> features command.
> Could you make it work for a "normal" GeometryCollection ?
>
> Micha�l
>
>
> regards,
> Larry
>
>
> 2010/3/12 Micha�l Michaud <michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>>
>
>
> @Micha�l, do you think it would be possible to
> just return the
> bad ring as a separate linestring instead of a
> part of a
> geometery collection?
>
> Currently Shapefile returns a big
> GeometryCollection made of all
> individual geometries of the file and
> ShapefileReader associate
> each getGeometryN to a dbf record.
> This is probably possible to do what you suggest,
> just adding
> dirty rings at the end, without attribute and
> without reference to
> the original Shape (not sure I like it however).
> May be it is also possible to keep dirty Polygons as
> GeometryCollection in the org....Shapefile class
> and to process
> those Geometries (separate Polygons from
> LineStrings) in the
> com....ShapefileReader class (so that attributes
> can be kept).
> On the other hand, adding dirty LinearRing to
> another Layer seems
> more difficult to me.
>
> Micha�l
>
>
> Larry
> 2010/3/11 Micha�l Michaud
> <michael...@free.fr <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>>>
>
>
> Hi,
>
>
> Assuming Micha�l is volunteering to
> into their own layer. If Micha�l can
> come up with a way to
> return status from the shapefile reader,
> I'll volunteer to
> break out the linestrings.
>
> This may be more difficult as it does not
> folow the simple
> schema
> one source file / one layer. I'll think a
> bit more about
> this problem.
> Anyway, I'll not do the change without
> making sure most of
> you agree.
>
> Micha�l
Larry Becker
Yes and no. New JTS did not accept any more the Point(null,null,0) used in EditTransaction.deleteFeature method.
Fixed in the svn repository (replaced by empty GeometryCollection)
Michaël
On Fri, Mar 12, 2010 at 5:09 PM, Larry Becker <becker...@gmail.com <mailto:becker...@gmail.com>> wrote:
Ah, I duplicated your problem with the latest code from SVN. So
it is a recent change...
On Fri, Mar 12, 2010 at 5:02 PM, Larry Becker
<becker...@gmail.com <mailto:becker...@gmail.com>> wrote:
Could you make it work for a "normal" GeometryCollection ?
Yes. I drew a few rectangles, linestrings, and points, then
combined them and successfully exploded them. OJ 1.3.1.
Larry
2010/3/12 Michaël Michaud <michael...@free.fr
I thing these three things are bug and should be
fix (with a
higher priority compared to bad shapefile reading
problem)
Ok, I'll take care of the Extract Layers by Geometry
Type bug. I guess correct behavior is to split the
mixed geometry types into separate geometry
collections (if more than one of a type) and replicate
the attributes?
I'm guessing that the bug with exploding a geometry
collection was caused by an invalid ring since it
works for "normal" cases.
No, unfortunately, I get it from a GeometryCollection
built in OpenJUMP from valid Geometries with the Combine
features command.
Could you make it work for a "normal" GeometryCollection ?
@Michaël, do you think it would be possible to
just return the
bad ring as a separate linestring instead of a
part of a
geometery collection?
Currently Shapefile returns a big
GeometryCollection made of all
individual geometries of the file and
ShapefileReader associate
each getGeometryN to a dbf record.
This is probably possible to do what you suggest,
just adding
dirty rings at the end, without attribute and
without reference to
the original Shape (not sure I like it however).
May be it is also possible to keep dirty Polygons as
GeometryCollection in the org....Shapefile class
and to process
those Geometries (separate Polygons from
LineStrings) in the
com....ShapefileReader class (so that attributes
can be kept).
On the other hand, adding dirty LinearRing to
another Layer seems
more difficult to me.
Michaël
Larry
2010/3/11 Michaël Michaud
<michael...@free.fr <mailto:michael...@free.fr>
<mailto:michael...@free.fr
<mailto:michael...@free.fr>>
<mailto:michael...@free.fr
<mailto:michael...@free.fr>
<mailto:michael...@free.fr
<mailto:michael...@free.fr>>>>
Hi,
Assuming Michaël is volunteering to
into their own layer. If Michaël can
come up with a way to
return status from the shapefile reader,
I'll volunteer to
break out the linestrings.
This may be more difficult as it does not
folow the simple
schema
one source file / one layer. I'll think a
bit more about
this problem.
Anyway, I'll not do the change without
making sure most of
you agree.
Michaël
Michaël Michaud
It is a bit more work. I let you fix it (are you the author ?).
To log bad features, building a FeatureCollection still seems much
easier and a bit more elegant than adding features or layer. However, I
admit this may be a complication for users with no background.
Here is my ultimate solution (kind of do-it-yourself though) :
Bad geometries (or parts) could be embeded in the cleaned geometry using
the Geometry#setUserData. This way, beginners could see clean
geometries, and advanced users could get original geometries or switch
to original geometries (or bad parts of the original geometries) from a
script (ex. beantools).
Micha�l
>
> 2010/3/13 Micha�l Michaud <michael...@free.fr
> <mailto:michael...@free.fr>>
>
> Larry Becker a �crit :
>
> I'm guessing the new JTS.
>
> Yes and no. New JTS did not accept any more the Point(null,null,0)
> used in EditTransaction.deleteFeature method.
> Fixed in the svn repository (replaced by empty GeometryCollection)
>
> Micha�l
>
>
> On Fri, Mar 12, 2010 at 5:09 PM, Larry Becker
> <becker...@gmail.com <mailto:becker...@gmail.com>
> <mailto:becker...@gmail.com
> <mailto:becker...@gmail.com>>> wrote:
>
> Ah, I duplicated your problem with the latest code from
> SVN. So
> it is a recent change...
>
>
> On Fri, Mar 12, 2010 at 5:02 PM, Larry Becker
> <becker...@gmail.com <mailto:becker...@gmail.com>
> <mailto:becker...@gmail.com
> <mailto:becker...@gmail.com>>> wrote:
>
> Could you make it work for a "normal"
> GeometryCollection ?
>
>
> Yes. I drew a few rectangles, linestrings, and points,
> then
> combined them and successfully exploded them. OJ 1.3.1.
>
>
> Larry
> 2010/3/12 Micha�l Michaud <michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>>
>
> Larry Becker a �crit :
>
>
> I thing these three things are bug and should be
> fix (with a
> higher priority compared to bad shapefile
> reading
> problem)
>
>
> Ok, I'll take care of the Extract Layers by
> Geometry
> Type bug. I guess correct behavior is to split the
> mixed geometry types into separate geometry
> collections (if more than one of a type) and
> replicate
> the attributes?
>
> I'm guessing that the bug with exploding a geometry
> collection was caused by an invalid ring since it
> works for "normal" cases.
>
> No, unfortunately, I get it from a GeometryCollection
> built in OpenJUMP from valid Geometries with the
> Combine
> features command.
> Could you make it work for a "normal"
> GeometryCollection ?
>
> Micha�l
>
>
> regards,
> Larry
>
>
> 2010/3/12 Micha�l Michaud
> <michael...@free.fr <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>>>
>
>
> @Micha�l, do you think it would be
> Micha�l
>
>
> Larry
> 2010/3/11 Micha�l Michaud
> <michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr <mailto:michael...@free.fr>>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>>>>
>
>
> Hi,
>
>
> Assuming Micha�l is volunteering to
> into their own layer. If Micha�l can
> come up with a way to
> return status from the shapefile
> reader,
> I'll volunteer to
> break out the linestrings.
>
> This may be more difficult as it does not
> folow the simple
> schema
> one source file / one layer. I'll think a
> bit more about
> this problem.
> Anyway, I'll not do the change without
> making sure most of
> you agree.
>
> Micha�l
Larry Becker
I like your ultimate solution. It sounds doable, keeps novices happy, and advanced users should be, well, advanced. I agree,the script should be fairly easy to write.
BTW, doesn't EditTransaction#createFeature need your fix as much as deleteFeature?
regards,
Larry
Larry Becker a écrit :
Thanks Michaël. I'm assuming this won't fix the " Extract Layers by Geometry Type" bug. I'll get to it soon.
No, I did not fix Extract Layers by Geometry Type. Just had a quick look.
It is a bit more work. I let you fix it (are you the author ?).
To log bad features, building a FeatureCollection still seems much easier and a bit more elegant than adding features or layer. However, I admit this may be a complication for users with no background.
Here is my ultimate solution (kind of do-it-yourself though) :
Bad geometries (or parts) could be embeded in the cleaned geometry using the Geometry#setUserData. This way, beginners could see clean geometries, and advanced users could get original geometries or switch to original geometries (or bad parts of the original geometries) from a script (ex. beantools).
Michaël
2010/3/13 Michaël Michaud <michael...@free.fr <mailto:michael...@free.fr>>
Larry Becker a écrit :
I'm guessing the new JTS.
Yes and no. New JTS did not accept any more the Point(null,null,0)
used in EditTransaction.deleteFeature method.
Fixed in the svn repository (replaced by empty GeometryCollection)
Michaël
Ah, I duplicated your problem with the latest code from
SVN. So
it is a recent change...
On Fri, Mar 12, 2010 at 5:02 PM, Larry Becker
<becker...@gmail.com <mailto:becker...@gmail.com>
Could you make it work for a "normal"
GeometryCollection ?
Yes. I drew a few rectangles, linestrings, and points,
then
combined them and successfully exploded them. OJ 1.3.1.
Larry
I thing these three things are bug and should be
fix (with a
higher priority compared to bad shapefile
reading
problem)
Ok, I'll take care of the Extract Layers by
Geometry
Type bug. I guess correct behavior is to split the
mixed geometry types into separate geometry
collections (if more than one of a type) and
replicate
the attributes?
I'm guessing that the bug with exploding a geometry
collection was caused by an invalid ring since it
works for "normal" cases.
No, unfortunately, I get it from a GeometryCollection
built in OpenJUMP from valid Geometries with the
Combine
features command.
Could you make it work for a "normal"
GeometryCollection ?
Michaël
regards,
Larry
2010/3/12 Michaël Michaud
@Michaël, do you think it would be
Michaël
Larry
2010/3/11 Michaël Michaud
<michael...@free.fr
<mailto:michael...@free.fr>
<mailto:michael...@free.fr <mailto:michael...@free.fr>>
<mailto:michael...@free.fr
<mailto:michael...@free.fr>
<mailto:michael...@free.fr
<mailto:michael...@free.fr>>>
<mailto:michael...@free.fr
<mailto:michael...@free.fr>
<mailto:michael...@free.fr
<mailto:michael...@free.fr>>
<mailto:michael...@free.fr
<mailto:michael...@free.fr>
<mailto:michael...@free.fr
<mailto:michael...@free.fr>>>>>
Hi,
Assuming Michaël is volunteering to
into their own layer. If Michaël can
come up with a way to
return status from the shapefile
reader,
I'll volunteer to
break out the linestrings.
This may be more difficult as it does not
folow the simple
schema
one source file / one layer. I'll think a
bit more about
this problem.
Anyway, I'll not do the change without
making sure most of
you agree.
Michaël
Michaël Michaud
>
> I like your ultimate solution. It sounds doable, keeps novices happy,
> and advanced users should be, well, advanced. I agree,the script
> should be fairly easy to write.
>
> BTW, doesn't EditTransaction#createFeature need your fix as much as
> deleteFeature?
Micha�l
>
> regards,
> Larry
> 2010/3/15 Micha�l Michaud <michael...@free.fr
> <mailto:michael...@free.fr>>
>
> Larry Becker a �crit :
>
> Thanks Micha�l. I'm assuming this won't fix the " Extract
> Layers by Geometry Type" bug. I'll get to it soon.
>
> No, I did not fix Extract Layers by Geometry Type. Just had a
> quick look.
> It is a bit more work. I let you fix it (are you the author ?).
>
> To log bad features, building a FeatureCollection still seems much
> easier and a bit more elegant than adding features or layer.
> However, I admit this may be a complication for users with no
> background.
> Here is my ultimate solution (kind of do-it-yourself though) :
> Bad geometries (or parts) could be embeded in the cleaned geometry
> using the Geometry#setUserData. This way, beginners could see
> clean geometries, and advanced users could get original geometries
> or switch to original geometries (or bad parts of the original
> geometries) from a script (ex. beantools).
>
> Micha�l
>
>
> 2010/3/13 Micha�l Michaud <michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr <mailto:michael...@free.fr>>>
>
> Larry Becker a �crit :
>
> I'm guessing the new JTS.
>
> Yes and no. New JTS did not accept any more the
> Point(null,null,0)
> used in EditTransaction.deleteFeature method.
> Fixed in the svn repository (replaced by empty
> GeometryCollection)
>
> Micha�l
>
>
> On Fri, Mar 12, 2010 at 5:09 PM, Larry Becker
> <becker...@gmail.com <mailto:becker...@gmail.com>
> <mailto:becker...@gmail.com <mailto:becker...@gmail.com>>
> <mailto:becker...@gmail.com
> <mailto:becker...@gmail.com>
> <mailto:becker...@gmail.com
> <mailto:becker...@gmail.com>>>> wrote:
>
> Ah, I duplicated your problem with the latest code from
> SVN. So
> it is a recent change...
>
>
> On Fri, Mar 12, 2010 at 5:02 PM, Larry Becker
> <becker...@gmail.com
> <mailto:becker...@gmail.com> <mailto:becker...@gmail.com
> <mailto:becker...@gmail.com>>
> <mailto:becker...@gmail.com
> <mailto:becker...@gmail.com>
> <mailto:becker...@gmail.com
> <mailto:becker...@gmail.com>>>> wrote:
>
> Could you make it work for a "normal"
> GeometryCollection ?
>
>
> Yes. I drew a few rectangles, linestrings, and
> points,
> then
> combined them and successfully exploded them.
> OJ 1.3.1.
>
>
> Larry
> 2010/3/12 Micha�l Michaud
> <michael...@free.fr <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>>>
>
> Larry Becker a �crit :
>
>
> Micha�l
>
>
> regards,
> Larry
>
>
> 2010/3/12 Micha�l Michaud
> <michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr <mailto:michael...@free.fr>>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>>>>
>
>
> @Micha�l, do you think it would be
> Micha�l
>
>
> Larry
> 2010/3/11 Micha�l Michaud
> <mailto:michael...@free.fr>>>>>>
>
>
> Hi,
>
>
> Assuming Micha�l is
> Micha�l can
> come up with a way to
> return status from the
> shapefile
> reader,
> I'll volunteer to
> break out the linestrings.
>
> This may be more difficult as
> it does not
> folow the simple
> schema
> one source file / one layer.
> I'll think a
> bit more about
> this problem.
> Anyway, I'll not do the change
> without
> making sure most of
> you agree.
>
> Micha�l
Michaël Michaud
After many discussions with Larry, I introduced what could be called
"Loren's feature" in the PolygonHandler of the shapefile reader.
It stores two kinds of invalid rings in a place called UserData,
available in each feature geometry :
- rings with more than 0 but less than 4 points
- rings having CCW orientation (should be holes), but which are not
nested in a CW ring
Firsts are cancelled by shapefile reader, seconds are read as plain polygons
To retrieve original invalid rings, I added a BeanTool script called
8-GetInvalidShapefileRings.bsh
When both the new reader and the new script will be available in the
daily build, I would be happy that you test it and give feedback.
Micha�l
Loren Slater a �crit :
>
> Hi Larry,
>
> I am able to reproduce the issue using ArcView 9.2 (Build 1500) using
> the previously posted files. Running the check geometry tool reports
> self intersections and the invalid shapes are visible. I am attaching
> a point file that contains the locations of the invalid areas. I know
> once upon a time I installed a patch to ArcView, not sure if that
> might be making a difference. Hope this helps.
>
> Thanks,
>
> Loren
>
>> On Mar 11, 2010 2:14 PM, "Larry Becker" <becker...@gmail.com
Giuseppe Aruta
-----------------------------------------------------------
Openjump NB
1) I draw a fance ona part of my project
2) Save view to image raster
3) Recived this error :
java.lang.NullPointerException
at com.vividsolutions.jump.workbench.ui.plugin.SaveImageAsPlugIn.execute(SaveImageAsPlugIn.java:183)
at com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:130)
at com.vividsolutions.jump.workbench.ui.plugin.FeatureInstaller$4$1.run(FeatureInstaller.java:581)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
---------------------------------------
Skyjump one of the last verions (108, I think)
1) load an image using Add jpeg layer
2) the image is displayed as layer on the Layer list but not displayed in the workbench
----------------------------
I'll do othe tests on both softwares
Peppe
Larry Becker
Thanks for the testing. Unfortunately, I wasn't able to duplicate the SkyJUMP problem. I need more information. Did you save a world file in OpenJump? Did you use right-click layer menu "Zoom to Layer" in SkyJUMP?
I did find the OpenJump code is failing because it was not internationalized. The Fence layer name is "Ausiliare" in Italian, but the code is looking for "Fence".
Layer fenceLayer = workbenchContext.getLayerNamePanel().getLayerManager().getLayer("Fence");
fenceLayer.setVisible(false);
I changed the code to:
String fenceLayerName = I18N.get("model.FenceLayerFinder.fence");
Layer fenceLayer = workbenchContext.getLayerNamePanel().getLayerManager().getLayer(fenceLayerName);
fenceLayer.setVisible(false);
regards,
Larry
To unsubscribe from this group, send email to openjump-users+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Sunburned Surveyor
Michael wrote: "It stores two kinds of invalid rings in a place called
UserData, available in each feature geometry."
Your talking about the storage in the Geometry object accessed by the
getUserData method, correct?
http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/Geometry.html
Landon
2010/3/21 Michaël Michaud <michael...@free.fr>:
> Hi Loren, Larry
>
> After many discussions with Larry, I introduced what could be called
> "Loren's feature" in the PolygonHandler of the shapefile reader.
> It stores two kinds of invalid rings in a place called UserData, available
> in each feature geometry :
> - rings with more than 0 but less than 4 points
> - rings having CCW orientation (should be holes), but which are not nested
> in a CW ring
> Firsts are cancelled by shapefile reader, seconds are read as plain polygons
>
> To retrieve original invalid rings, I added a BeanTool script called
> 8-GetInvalidShapefileRings.bsh
>
> When both the new reader and the new script will be available in the daily
> build, I would be happy that you test it and give feedback.
>
> Michaël
>
> Loren Slater a écrit :
>>
>> Hi Larry,
>>
>> I am able to reproduce the issue using ArcView 9.2 (Build 1500) using the
>> previously posted files. Running the check geometry tool reports self
>> intersections and the invalid shapes are visible. I am attaching a point
>> file that contains the locations of the invalid areas. I know once upon a
>> time I installed a patch to ArcView, not sure if that might be making a
>> difference. Hope this helps.
>>
>> Thanks,
>>
>> Loren
>>
>>> On Mar 11, 2010 2:14 PM, "Larry Becker" <becker...@gmail.com
>>> <mailto:becker...@gmail.com>> wrote:
>>>
>>> Loren,
>>>
>>> I opened your latest attachment in ArcMap 9.2 and it didn't report any
>>> errors. Visually the last multipolygon looked the same in ESRI as it did in
>>> OpenJump.
>>>
>>> regards,
>>> Larry
>>>
>>>
>>>
>>> On Wed, Mar 10, 2010 at 11:02 AM, Larry Becker <becker...@gmail.com
>>> <mailto:becker...@gmail.com>> wrote:
>>> >
>>> > Isn't one of th...
>>>
>
Stefan Steiniger
Michaël Michaud
> Sounds like you've found a good solution Michael. Thanks for the improvements.
>
> Michael wrote: "It stores two kinds of invalid rings in a place called
> UserData, available in each feature geometry."
>
> Your talking about the storage in the Geometry object accessed by the
> getUserData method, correct?
>
We'll see if the solution is ok for Loren
Micha�l
> http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/Geometry.html
>
> Landon
>
> 2010/3/21 Micha�l Michaud <michael...@free.fr>:
>
>> Hi Loren, Larry
>>
>> After many discussions with Larry, I introduced what could be called
>> "Loren's feature" in the PolygonHandler of the shapefile reader.
>> It stores two kinds of invalid rings in a place called UserData, available
>> in each feature geometry :
>> - rings with more than 0 but less than 4 points
>> - rings having CCW orientation (should be holes), but which are not nested
>> in a CW ring
>> Firsts are cancelled by shapefile reader, seconds are read as plain polygons
>>
>> To retrieve original invalid rings, I added a BeanTool script called
>> 8-GetInvalidShapefileRings.bsh
>>
>> When both the new reader and the new script will be available in the daily
>> build, I would be happy that you test it and give feedback.
>>
>> Micha�l
>>
>> Loren Slater a �crit :
>>
Loren Slater
Yes that's it.
Sounds like you've found a good solution Michael. Thanks for the improvements.
Michael wrote: "It stores two kinds of invalid rings in a place called
UserData, available in each feature geometry."
Your talking about the storage in the Geometry object accessed by the
getUserData method, correct?
We'll see if the solution is ok for Loren
Michaël
http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/Geometry.html
Landon
2010/3/21 Michaël Michaud <michael...@free.fr>:
Hi Loren, Larry
After many discussions with Larry, I introduced what could be called
"Loren's feature" in the PolygonHandler of the shapefile reader.
It stores two kinds of invalid rings in a place called UserData, available
in each feature geometry :
- rings with more than 0 but less than 4 points
- rings having CCW orientation (should be holes), but which are not nested
in a CW ring
Firsts are cancelled by shapefile reader, seconds are read as plain polygons
To retrieve original invalid rings, I added a BeanTool script called
8-GetInvalidShapefileRings.bsh
When both the new reader and the new script will be available in the daily
build, I would be happy that you test it and give feedback.
Michaël
Loren Slater a écrit :
Hi Larry,
Larry Becker
You can find the nightly snapshot at: http://jump-pilot.sourceforge.net/download/nightlybuild/
Just download the latest zip file and extract it over your existing openjump folder.
Larry
Giuseppe Aruta
| Hi Larry, thanks for your very quick solution, I vote with Stefan for you as the "Developer for Month 2010". I am out for work, I wil be back home on the next week. It's on my schedule to test again SkyJump Export High Resolution Image and write back. regards Peppe --- Lun 22/3/10, Larry Becker <becker...@gmail.com> ha scritto:
|
Michaël Michaud
Did you test the new code ?
Also, I would like to know if the bug report Stefan reported for you can
be closed or if it still an issue for you. See :
http://sourceforge.net/tracker/?func=detail&aid=2788633&group_id=118054&atid=679906
Thanks for your help,
Micha�l
Loren Slater a �crit :
>
> Thanks for working this out for me. From what I've read, I will be
> able to use a beantool script to display any invalid features captured
> during the loading process. That works for me, just let me know where
> to get the updated OJ build and the new script.
>
> Thanks,
>
> Loren
>
> <mailto:michael...@free.fr>>
>
> Sunburned Surveyor a �crit :
> Sounds like you've found a good solution Michael. Thanks for
> the improvements.
>
> Michael wrote: "It stores two kinds of invalid rings in a
> place called
> UserData, available in each feature geometry."
>
> Your talking about the storage in the Geometry object accessed
> by the
> getUserData method, correct?
>
>
> Yes that's it.
> We'll see if the solution is ok for Loren
>
>
> http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/Geometry.html
>
> Landon
>
> 2010/3/21 Micha�l Michaud <michael...@free.fr
> <mailto:michael...@free.fr>>:
>
> Hi Loren, Larry
>
> After many discussions with Larry, I introduced what could
> be called
> "Loren's feature" in the PolygonHandler of the shapefile
> reader.
> It stores two kinds of invalid rings in a place called
> UserData, available
> in each feature geometry :
> - rings with more than 0 but less than 4 points
> - rings having CCW orientation (should be holes), but
> which are not nested
> in a CW ring
> Firsts are cancelled by shapefile reader, seconds are read
> as plain polygons
>
> To retrieve original invalid rings, I added a BeanTool
> script called
> 8-GetInvalidShapefileRings.bsh
>
> When both the new reader and the new script will be
> available in the daily
> build, I would be happy that you test it and give feedback.
>
>
> Loren Slater a �crit :
>
> Hi Larry,
>
> I am able to reproduce the issue using ArcView 9.2
> (Build 1500) using the
> previously posted files. Running the check geometry
> tool reports self
> intersections and the invalid shapes are visible. I
> am attaching a point
> file that contains the locations of the invalid areas.
> I know once upon a
> time I installed a patch to ArcView, not sure if that
> might be making a
> difference. Hope this helps.
>
> Thanks,
>
> Loren
>
>
>
> On Mar 11, 2010 2:14 PM, "Larry Becker"
> <becker...@gmail.com
> <mailto:becker...@gmail.com>
>
> Loren,
>
> I opened your latest attachment in ArcMap 9.2 and
> it didn't report any
> errors. Visually the last multipolygon looked the
> same in ESRI as it did in
> OpenJump.
>
> regards,
> Larry
>
>
>
> On Wed, Mar 10, 2010 at 11:02 AM, Larry Becker
> <becker...@gmail.com
> <mailto:becker...@gmail.com>
>
>
> Isn't one of th...
>
>
> To unsubscribe from this group, send email to
> openjump-users+unsubscribegooglegroups.com
> words "REMOVE ME" as the subject.
>
>
>
>
> To unsubscribe from this group, send email to
> openjump-users+unsubscribegooglegroups.com
>
>
>
>
>
> To unsubscribe from this group, send email to
> openjump-users+unsubscribegooglegroups.com
Michaël Michaud
Would be great to have feedback about the bug fix before I definitely
close the bug report.
Thanks for your help.
Micha�l
Loren Slater
Hi Loren,
Would be great to have feedback about the bug fix before I definitely close the bug report.
Thanks for your help.
Michaël
Michaël
Loren Slater a écrit :
Hi,
Thanks for working this out for me. From what I've read, I will be able to use a beantool script to display any invalid features captured during the loading process. That works for me, just let me know where to get the updated OJ build and the new script. Thanks,
Loren
2010/3/22 Michaël Michaud <michael...@free.fr <mailto:michael...@free.fr>>
Sunburned Surveyor a écrit :
Sounds like you've found a good solution Michael. Thanks for
the improvements.
Michael wrote: "It stores two kinds of invalid rings in a
place called
UserData, available in each feature geometry."
Your talking about the storage in the Geometry object accessed
by the
getUserData method, correct?
Yes that's it.
We'll see if the solution is ok for Loren
Michaël
http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/Geometry.html
Landon
2010/3/21 Michaël Michaud <michael...@free.fr
<mailto:michael...@free.fr>>:
Hi Loren, Larry
After many discussions with Larry, I introduced what could
be called
"Loren's feature" in the PolygonHandler of the shapefile
reader.
It stores two kinds of invalid rings in a place called
UserData, available
in each feature geometry :
- rings with more than 0 but less than 4 points
- rings having CCW orientation (should be holes), but
which are not nested
in a CW ring
Firsts are cancelled by shapefile reader, seconds are read
as plain polygons
To retrieve original invalid rings, I added a BeanTool
script called
8-GetInvalidShapefileRings.bsh
When both the new reader and the new script will be
available in the daily
build, I would be happy that you test it and give feedback.
Michaël
Michaël Michaud
Thanks to answer and sorry for poor explanations.
You shouldn't have to use the BeanshellEditor.
I added a BeanTool which is a small beanshell script "ready to be used"
Customize > BeanTools > 8- GetInvalidShapefileRings
1. Load the layer with the invalid shapes.
2. In OpenJump, Click Customize > BeanTools > 8- GetInvalidShapefileRings
You should get this message :
3.OK
If everything is fine, the BeanTool acts as a plugin and switch the
geometry corrected by OpenJUMP importer with original degenerated
geometries represented as linear rings.
If I can remember, another click on the command and you get corrected
data back.
Micha�l
Loren Slater a �crit :
> Hi Michael,
>
> I'm not very familiar with the beanshell editor and its usage. So, I
> might be missing a step here.. the steps I have taken to try and use
> the script are:
>
> 1. Load the layer with the invalid shapes.
> 2. In OpenJump, Click Scripting -> BeanShellEditorPlugin...
> 3. In the BeanShell Editor, Expand BeanTools folder.
> 4. Open #8 GetInvalidShapefileRings...
> 5. Click "Go!"
> 6. dialog box pops up, I click "OK"
> 7. nothing seems to happen after this...
>
> Beanshell Editor Output says "
>
> Sourced file: inline evaluation of:
> ``////////////////////////////////////////////////////////////////////////////////
> . . . '' : Unknown class: FeatureDataset : at Line: 27 : in file:
> inline evaluation of:
> ``////////////////////////////////////////////////////////////////////////////////
> . . . '' : new FeatureDataset ( layer .featureCollectionWrapper
> .featureSchema .clone ( ) )"
>
> followed by stack trace -> at
> bsh.BSHAllocationExpression.objectAllocation(Unknown Source), etc.
>
> Am I doing something wrong?
>
>
> 2010/6/22 Micha�l Michaud <michael...@free.fr
> <mailto:michael...@free.fr>>
>
> Hi Loren,
>
> Would be great to have feedback about the bug fix before I
> definitely close the bug report.
>
>
> Thanks for your help.
>
> Micha�l
>
>
> Micha�l
>
> Loren Slater a �crit :
>
> Hi,
>
> Thanks for working this out for me. From what I've read,
> I will be able to use a beantool script to display any
> invalid features captured during the loading process.
> That works for me, just let me know where to get the
> updated OJ build and the new script. Thanks,
>
> Loren
>
> 2010/3/22 Micha�l Michaud <michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>>
>
> Sunburned Surveyor a �crit :
>
> Sounds like you've found a good solution Michael.
> Thanks for
> the improvements.
>
> Michael wrote: "It stores two kinds of invalid
> rings in a
> place called
> UserData, available in each feature geometry."
>
> Your talking about the storage in the Geometry
> object accessed
> by the
> getUserData method, correct?
> Yes that's it.
> We'll see if the solution is ok for Loren
>
> Micha�l
>
>
> http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/Geometry.html
>
>
> Landon
>
> 2010/3/21 Micha�l Michaud <michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> Micha�l
>
>
>
Loren Slater
Michaël Michaud
> to use it with the previous version...
Micha�l
>
> On Tue, Jun 22, 2010 at 3:00 PM, Loren Slater <loren....@gmail.com
> <mailto:loren....@gmail.com>> wrote:
>
> Hi Michael,
>
> I'm not very familiar with the beanshell editor and its usage.
> So, I might be missing a step here.. the steps I have taken to
> try and use the script are:
>
> 1. Load the layer with the invalid shapes.
> 2. In OpenJump, Click Scripting -> BeanShellEditorPlugin...
> 3. In the BeanShell Editor, Expand BeanTools folder.
> 4. Open #8 GetInvalidShapefileRings...
> 5. Click "Go!"
> 6. dialog box pops up, I click "OK"
> 7. nothing seems to happen after this...
>
> Beanshell Editor Output says "
>
> Sourced file: inline evaluation of:
> ``////////////////////////////////////////////////////////////////////////////////
> . . . '' : Unknown class: FeatureDataset : at Line: 27 : in file:
> inline evaluation of:
> ``////////////////////////////////////////////////////////////////////////////////
> . . . '' : new FeatureDataset ( layer .featureCollectionWrapper
> .featureSchema .clone ( ) )"
>
> followed by stack trace -> at
> bsh.BSHAllocationExpression.objectAllocation(Unknown Source), etc.
>
> Am I doing something wrong?
>
>
> 2010/6/22 Micha�l Michaud <michael...@free.fr
> <mailto:michael...@free.fr>>
>
> Hi Loren,
>
> Would be great to have feedback about the bug fix before I
> definitely close the bug report.
>
>
> Thanks for your help.
>
> Micha�l
>
>
> Micha�l
>
> Loren Slater a �crit :
>
> Hi,
>
> Thanks for working this out for me. From what I've
> read, I will be able to use a beantool script to
> display any invalid features captured during the
> loading process. That works for me, just let me know
> where to get the updated OJ build and the new script.
> Thanks,
>
> Loren
>
> 2010/3/22 Micha�l Michaud <michael...@free.fr
> <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> <mailto:michael...@free.fr>>>
>
> Sunburned Surveyor a �crit :
>
> Sounds like you've found a good solution
> Michael. Thanks for
> the improvements.
>
> Michael wrote: "It stores two kinds of invalid
> rings in a
> place called
> UserData, available in each feature geometry."
>
> Your talking about the storage in the Geometry
> object accessed
> by the
> getUserData method, correct?
> Yes that's it.
> We'll see if the solution is ok for Loren
>
> Micha�l
>
>
> http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/Geometry.html
>
>
> Landon
>
> 2010/3/21 Micha�l Michaud
> <michael...@free.fr <mailto:michael...@free.fr>
> <mailto:michael...@free.fr
> Micha�l
>
>
>
>