Re: [JPP-Devel] Spatialite multigeometry trouble and JTS v. 1.13

[Martin Davis]

Yep, I'll make the change shortly.

On 4/21/2013 8:22 PM, Larry Reeder wrote:
Martin,  I agree that the JTS WKBReader shouldn't be hacked to support 
the SpatialLite BLOB format or whatever else come along with a 
slightly different interpretation of the standard, and this is a great 
compromise solution.   Is this change something we can expect in JTS 1.14?


Thankslreeder


On Sun, Apr 21, 2013 at 10:19 AM, Martin Davis <mailto:mtncl...@telus.net>> wrote:


Hey guys, I have been lurking on this thread...

I agree that it would be bizarre to switch endianess in the middle
of a
WKB blob.  I suspect that the standard did not really have the
intent of
supporting this, they just provided multiple endian code items as a
side-effect of reusing the definition of the component WKB
representations.

In fact, now that I reread it, the JTS bug report that caused the
change
in JTS 1.13

(http://sourceforge.net/tracker/?func=detail&aid=3543534&group_id=128875&atid=713120)
wasn't about supporting internal endian change, but about the fact
that
the JTS 1.12 WKBReader wouldn't change endianess *ever*, even between
different geometries.  This of course is a definite bug. But the fix
went a little further than necessary, perhaps.

I'm not keen on explicitly committing to support SpatialLite BLOB
format
in JTS, since that's just a bunch more to test.  But how about
this for
a solution?  The WKBReader can be changed to only switch endianess
when
the code is one of the two specified in the standard (0 =
BigEndian, 1 =
LittleEndian). If any other code is read then the endianess will
be left
unchanged.  That should handle the SpatialLite BLOB format, right? And
it avoids any explicit dependency on magic numbers from SpatialLite.
And it still allows switching endianness mid-WKB, as per the standard,
should anyone be so perverse as to do that.

This is pretty much Michael's suggestion, but even simpler.  I won't
bother throwing an error message for now.  There is an unused
provision
for a "strict" flag in WKBReader - perhaps at some point that can be
exposed and in that case an error could be thrown. In general
though it
seems better to be lenient when reading.

Martin



On 4/21/2013 8:27 AM, edgar.sol...@web.de
<mailto:edgar.sol...@web.de> wrote:
> On 21.04.2013 17 :13, Michaël Michaud wrote:
>> Hi
>>> well - the SRID code is the only thing that seems to be added
between JTS 1.7 and 1.8.
>>>
>>> some more observations:
>>>
>>> what Larry's DBQuery actually does is stripping MBR header and
end marker from the spatiallite blob and handing it over to JTS.
as Michael correctly discovered is the endianess byte used
differently in there, so what actually would need to be done is
the WKB would have to be postprocessed before giving it to JTS.
but before we try that:
>>>
>>> i had a look at
>>>

https://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=OpenJUMP_with_SpatialLite#Using_SpatiaLite_with_Spatialite_Reader_Plugin
>>> sources and it seems to bring with a full blown BLOB parser.
>>>
>>> Jukka, Michael: could you check if this plugin suffers from
the same problem? i would guess not. if not, we could reuse the
parser, single it out as a jar etc.
>> I recently patched Spatialite Plugin after Jukka'request, but
it suffers
>> from the same problem (parser just read the first few bytes
then use JTS
>> WKBReader).
>>
>> I had a look in JTS WKBParser (which is short and easy to read).
>>
>> The key part is in readGeometry(), lines
>>   int byteOrder = byteOrderWKB == WKBConstants.wkbNDR ?
>> ByteOrderValues.LITTLE_ENDIAN : ByteOrderValues.BIG_ENDIAN;
>>   dis.setOrder(byteOrder);
>>
>> Unfortunately, this method is private.
>> We could suggest to Martin to change it to
>>
>>   switch(byteOrderWKB) {
>>   case WKBConstants.wkbNDR:
>> dis.setOrder(ByteOrderValues.LITTLE_ENDIAN);
>>   break;
>>   case
WKBConstants.wkbXDR:dis.setOrder(ByteOrderValues.BIG_ENDIAN);
>>   break;
>>   case 0x69 : // keep previous byte order, this is a
spatialite
>> geometry
>>   break;
>>   default :
>>   throw Exception("This case is neither a pure wkb
neither a
>> spatialite wkb");
>>   }
&g

Re: [JPP-Devel] Spatialite multigeometry trouble and JTS v. 1.13

[Martin Davis]

Hey guys, I have been lurking on this thread...

I agree that it would be bizarre to switch endianess in the middle of a 
WKB blob.  I suspect that the standard did not really have the intent of 
supporting this, they just provided multiple endian code items as a 
side-effect of reusing the definition of the component WKB representations.

In fact, now that I reread it, the JTS bug report that caused the change 
in JTS 1.13 
(http://sourceforge.net/tracker/?func=detail&aid=3543534&group_id=128875&atid=713120)
 
wasn't about supporting internal endian change, but about the fact that 
the JTS 1.12 WKBReader wouldn't change endianess *ever*, even between 
different geometries.  This of course is a definite bug. But the fix 
went a little further than necessary, perhaps.

I'm not keen on explicitly committing to support SpatialLite BLOB format 
in JTS, since that's just a bunch more to test.  But how about this for 
a solution?  The WKBReader can be changed to only switch endianess when 
the code is one of the two specified in the standard (0 = BigEndian, 1 = 
LittleEndian). If any other code is read then the endianess will be left 
unchanged.  That should handle the SpatialLite BLOB format, right? And 
it avoids any explicit dependency on magic numbers from SpatialLite.  
And it still allows switching endianness mid-WKB, as per the standard, 
should anyone be so perverse as to do that.

This is pretty much Michael's suggestion, but even simpler.  I won't 
bother throwing an error message for now.  There is an unused provision 
for a "strict" flag in WKBReader - perhaps at some point that can be 
exposed and in that case an error could be thrown. In general though it 
seems better to be lenient when reading.

Martin



On 4/21/2013 8:27 AM, edgar.sol...@web.de wrote:
> On 21.04.2013 17:13, Michaël Michaud wrote:
>> Hi
>>> well - the SRID code is the only thing that seems to be added between JTS 
>>> 1.7 and 1.8.
>>>
>>> some more observations:
>>>
>>> what Larry's DBQuery actually does is stripping MBR header and end marker 
>>> from the spatiallite blob and handing it over to JTS. as Michael correctly 
>>> discovered is the endianess byte used differently in there, so what 
>>> actually would need to be done is the WKB would have to be postprocessed 
>>> before giving it to JTS. but before we try that:
>>>
>>> i had a look at
>>>
>>> https://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=OpenJUMP_with_SpatialLite#Using_SpatiaLite_with_Spatialite_Reader_Plugin
>>> sources and it seems to bring with a full blown BLOB parser.
>>>
>>> Jukka, Michael: could you check if this plugin suffers from the same 
>>> problem? i would guess not. if not, we could reuse the parser, single it 
>>> out as a jar etc.
>> I recently patched Spatialite Plugin after Jukka'request, but it suffers
>> from the same problem (parser just read the first few bytes then use JTS
>> WKBReader).
>>
>> I had a look in JTS WKBParser (which is short and easy to read).
>>
>> The key part is in readGeometry(), lines
>>   int byteOrder = byteOrderWKB == WKBConstants.wkbNDR ?
>> ByteOrderValues.LITTLE_ENDIAN : ByteOrderValues.BIG_ENDIAN;
>>   dis.setOrder(byteOrder);
>>
>> Unfortunately, this method is private.
>> We could suggest to Martin to change it to
>>
>>   switch(byteOrderWKB) {
>>   case WKBConstants.wkbNDR:
>> dis.setOrder(ByteOrderValues.LITTLE_ENDIAN);
>>   break;
>>   case WKBConstants.wkbXDR:dis.setOrder(ByteOrderValues.BIG_ENDIAN);
>>   break;
>>   case 0x69 : // keep previous byte order, this is a spatialite
>> geometry
>>   break;
>>   default :
>>   throw Exception("This case is neither a pure wkb neither a
>> spatialite wkb");
>>   }
>>
>> Seems that it could tolerate spatialite geometry and be as strict as it
>> is now for wkb.
>>
>> What do you think ?
>>
> oh. i see, the reader switches to big endian because of the 0x69 value.. 
> can't be good ;)
> wrt. to the patch.
> it works around the standard. having a switch case is good, to find corrupt 
> datasets.
> adding spatialite specifics is a mixup of standards. maybe a class that 
> extends JTS's WKBParser implementing the specifics (cutting header,end, 0x69) 
> would be a cleaner solutions.
>
> but as you say: up to Martin. we can always extend WKBParser ourselfs if he 
> doesn't like it upstream.
>
> ..ede
>


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/list

Re: [JPP-Devel] The new geometry is invalid. Cancelled.

[Martin Davis]

As Michael and Stefan point out, Polygons in a MultiPolygon must be 
edge-disjoint (which another way of stating the formal definition "must 
only touch at a finite number of points".  If they touched along an 
edge, that would cause an infinite number of points to be coincident).

Another way of looking at this is that MultiPolygons are in a sense the 
canonical description of a given area of the plane.  If edge touches or 
overlaps were allowed then there would be an infinite number of 
geometries which described the same area.

Also, from the point of view of computing polygon overlay and spatial 
relationships this is a nice rule to have, since it reduces the number 
of cases which need to be checked for.  This makes the code simpler and 
more performant.  The cost is that it is necessary to ensure that 
MultiPolygons are valid at creation time.  This is a reasonable 
tradeoff, since in general geometries are queried more often than they 
are created.

GeometryCollections on the other hand have no particular semantics - 
they are just "bags" of geometries.  This makes them useful for holding 
arbitrary sets of geometries, but makes them more complex (and sometimes 
slower) to process.

On 4/8/2013 11:04 AM, Michaël Michaud wrote:
> Hi Uwe, Stefan,
>
> OpenJUMP (JTS) is right, this MultiPolygon is not OGC conform
>
> Here is the citation :
> Multipolygon
> 2. The Boundaries of any 2 Polygons that are elements of a MultiPolygon
> may not ‘cross’ and may touch
> at only a finite number of points. (Note that crossing is prevented by
> assertion 1 above).
>
> Don't ask me why, I've always thought it is strange that lines can
> share their boundaries in a MultiLineString and polygons cannot
> share an edge in a MultiPolygon, but it's a well established rule
> that JTS follows.
>
> Michaël
>
>
>> Hi Uwe,
>>
>> I am not sure I would call it a bug. OJ, should (try to) create data
>> that are OGC conform, but in this case it doesn't. Which means, the case
>> needs special treatment, but this is not implemented.
>>
>> That the multi-polygon causes an error is with the OGS SF specification
>> = correct. However, that the geometry collection does not cause an error
>> should be correct aw well, because there is, I believe, nothing said
>> about geometry collections and their validity. Geometry collections
>> should be allowed to have any type of geometries in what ever way they
>> are drawn - like a "container". If we would check geometry collections
>> for their validity it may be that people cannot store anymore the data
>> they have. Hence, checking should be optional.
>>
>> But I guess here, Michael M. knows probably more about OGC conformance?
>> I'll also cc to JTS list.
>>
>> cheers,
>> stefan
>>
>> PS: the Multi-polygon:
>>
>> MULTIPOLYGON (((
>>80 125,
>>80 241,
>>175 241,
>>175 125,
>>80 125
>>)), ((
>>175 125,
>>175 241,
>>263 241,
>>263 125,
>>175 125
>>)))
>>
>> Am 08.04.13 09:48, schrieb Uwe Dalluege:
>>> Hi Stefan,
>>>
>>> I am afraid I do not understand :-(
>>> Do you think this is a bug in OJ?
>>> The multipolygon causes an error
>>> the geometrycollection not.
>>>
>>> Is this behaviour OGC-conform (simpel features...)?
>>> What do you think?
>>>
>>> uwe
>>>
>>> Am 08.04.2013 16:36, schrieb Stefan Steiniger:
 Hi,

 so - well the situation is not so nice, as it should be valid. However,
 the JTS TestBuilder says the Multi-Polgyon is invalid because of
 "Self-intersection at or near point (175.0, 125.0, NaN)"

 Same message appears when you try to add it as a new feature.

 maybe you can make it valid before by running a zero-buffer over it?

 stefan

 Am 08.04.13 07:30, schrieb Uwe Dalluege:
> Hi,
>
> if you put a third geometrie to the two polygons,
> for instance a linestring, and combine them
> you will receive a geometrycollection
> and not a multipolygon.
>
> The geometrycollection causes *no* errors
> but the multipolygon.
>
> Uwe
>
>
> Am 08.04.2013 12:05, schrieb Uwe Dalluege:
>> Hi,
>>
>> I get the error:
>>
>> "The new geometry is invalid. Cancelled."
>> and I am not shure whether this error is correct.
>>
>> 1. Switch "Snap to vertices" option.
>>
>> 2. Draw a rectangle.
>>
>> 3. Draw a second rectangle with two identical
>> vertices from the first rectangle (with snap).
>>
>> 4. Select the two rectangles and
>> "Combine Selected features"
>>
>> 5. Try to move this multipolygon with
>> "Move Selected Items Tool".
>>
>> 6. The error appears
>> "The new geometry is invalid. Cancelled."
>>
>> 7. The QA>Validate Selected Layers...
>> causes a self-intersection in *one* point.
>>
>> Is this a bug in O

Re: [JPP-Devel] RoadMatcher PlugIn StackOverflowError

[Martin Davis]

The FUTURE classes are ones that added or enhanced functionality of 
classes which weren't easily changed directly.  For example, sometimes 
JUMP/JCS would need to move faster than JTS, so the JTS code was forked, 
updated, and then named FUTURE.


That's my memory of how it worked, anyway...

On 10/26/2012 11:37 AM, Michaël Michaud wrote:

Hi,

ah good to know.
So someone knows then about "FUTURE_FeatureInstaller"... MM?
In JCS code (and apparently in Roadmatcher) there are **many** classes 
called FUTURE_xxx

I guess it was a preparation for a new release.
In OpenJUMP, we still have a relic 
(com.vividsolutions.jump.io.FUTURE_JTS_WKTWriter)
I have deprecated the whole class one year ago because ther eis now a 
better one in JTS.


That's all what I know about future ;-)

Michaël*
*

well.. for me Friday has just begun. So still a bit away from weekend ;)

I am listening to German radio in the morning... and hear that holidays
begin there and streets are crowded today.

stefan

Am 26.10.12 10:20, schrieb Uwe Dalluege:

Hi Stefan,

the RoadMatcher-PlugIn was not so easy to find
because it is hidden under "More Plugins"

http://sourceforge.net/projects/jump-pilot/files/OpenJUMP_plugins/More%20Plugins/


Now it works in the latest snapshot
(Thanks to Ede!)

Have a nice weekend!

uwe


Am 26.10.2012 15:10, schrieb Stefan Steiniger:

Hi Uwe,

if I understood, put it in: /lib/ext/
what Ede tries to say is that subfolders of lib/ext/ will not be browsed
anymore, only the ext folder itself.

Maybe another question: where did you download the roadmatcher from?
from our SourceForge page?

cheers,
stefan

Am 26.10.12 09:30, schrieb Uwe Dalluege:

sorry... thats too high for me :-(

Belongs

jcommon-0.8.4.jar
jfreechart-0.9.9.jar
roadmatcher14forOJ.jar

to lib/ext or to lib?

uwe


Am 26.10.2012 14:23, schriebedgar.sol...@web.de:

if it pop's up with a class not found error yes... i am not sure
anymore about the changes i did during the startup speedup for 1.5.2
.. lib/ext/jars might end up in the classpath. jars in subfolders
like lib/ext/foobar/ will definitely not end up in classpath anymore.

something like dat.. ede

On 26.10.2012 14:16, Uwe Dalluege wrote:

what do you mean?
I found three jar files in the roadmatcher zip file
and put them to /lib/ext

jcommon-0.8.4.jar
jfreechart-0.9.9.jar
roadmatcher14forOJ.jar

Was this wrong?

uwe


Am 26.10.2012 14:08, schriebedgar.sol...@web.de:

please try revision 3052.. should work now
keep in mind extension jar belongs to lib/ext, other jars into lib/

..ede

On 26.10.2012 13:22, Uwe Dalluege wrote:

Hi Ede,

now I tested it with:
Version 20121025 snapshot rev.3051
25. October 2012

and I got the same error!


Regards

Uwe


Am 26.10.2012 12:24, schriebedgar.sol...@web.de:

does this happen with the current snapshot also? could you plesae
try?

anybody an idea what
com.vividsolutions.jcs.jump.FUTURE_FeatureInstaller actually is?

..ede



On 26.10.2012 10:45, Uwe Dalluege wrote:

Hi,

after I copy the RoadMatcher-PlugIn (3 files) to the lib\ext
directory I get an error when starting OpenJUMP 1.5.2




java.lang.StackOverflowError
at
com.vividsolutions.jump.workbench.ui.plugin.FeatureInstaller.addPopupMenuItem(FeatureInstaller.java:666)


at
com.vividsolutions.jcs.jump.FUTURE_FeatureInstaller.addPopupMenuItem(FUTURE_FeatureInstaller.java:25)


at
com.vividsolutions.jump.workbench.ui.plugin.FeatureInstaller.addPopupMenuItem(FeatureInstaller.java:666)


at
com.vividsolutions.jcs.jump.FUTURE_FeatureInstaller.addPopupMenuItem(FUTURE_FeatureInstaller.java:25)


at
com.vividsolutions.jump.workbench.ui.plugin.FeatureInstaller.addPopupMenuItem(FeatureInstaller.java:666)


at
com.vividsolutions.jcs.jump.FUTURE_FeatureInstaller.addPopupMenuItem(FUTURE_FeatureInstaller.java:25)


at
com.vividsolutions.jump.workbench.ui.plugin.FeatureInstaller.addPopupMenuItem(FeatureInstaller.java:666)


at
com.vividsolutions.jcs.jump.FUTURE_FeatureInstaller.addPopupMenuItem(FUTURE_FeatureInstaller.java:25)


at



Regards

Uwe

--


Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


--


Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


---

Re: [JPP-Devel] Linking Features with attributes from other FCs?

[Martin Davis]

I'm reading this...  Cool idea, definitely.   But it gets into deep 
water very quickly, depending on how fancy you want to get.

I don't think there's anything in the current model that limits this per 
se - this kind of functionality would be built underneath the current 
FeatureCollection and DataSource interfaces.

The easiest step in this direction is to add the ability to join to a 
layer that is already in memory.  It sounds like mentaer has made some 
steps in this direction, but in a "materialized" way.  The next step is 
to make the join to the memory layer dynamic, so it is executed on the 
fly, without requiring new storage to be allocated for the join layer.  
This can be pretty efficient if suitable indexes are created for the 
join condition to use.

Dynamic joining to an in-memory layer should work fine for 
dynamically-loaded datasources, too.  It's only when both sides of the 
join are loaded in a streaming fashion that it gets inefficient to 
perform the join in the client.  To make this efficient the join needs 
to be sent to the underlying datastore - which of course requires both 
join layers to be in the same datastore.  And then things might get 
harder, if it requires expression translation to convert the join 
condition to the language understood by the datastore.

I've been wrestling with this as well, because JEQL does this already.  
But it has a slightly easier problem, because it doesn't have to worry 
about redrawing a screenful of data.  In JEQL the general rule is that 
the driving (left-hand) layer (table) of the join can be streamed, but 
the one or more child join tables should be in-memory to give good 
performance.  This is equivalent to what I outlined above.

I have had thoughts about linking JEQL to JUMP, with one of the goals to 
support this kind of capability  But finding time is always an issue.

Martin




On 10/4/2012 4:05 PM, Stefan Steiniger wrote:
> thanks for the input Michael.
> Lets hope Martin reads this?
>
> stefan
>
> Am 04.10.12 16:58, schrieb Michaël Michaud:
>> Hi
>>> with respect to Bernds request (He actually wants a "link").
>>>
>>> Does anybody know if we can do links, like DB table joins?
>>> C
>> I think this is possible, and would be an interesting project.
>> If someone is interested, I think the most useful classes in OJ
>> are abstract class DataSource, and its implementation like
>> DataStoreDataSource or DataStoreQueryDataSource.
>> Difficulty may depends on the type of synchronization :
>> - from table to FeatureCollection only or bi-directionnal
>> - on load only or at every change
>> ...
>>
>> my 2 cents,
>>
>> Michaël
>>> ould it be that the Feature-Model of OJ restricts that.. as this would
>>> need to be defined somewhere in the FeatureSchema?
>>> What do you think?
>>>
>>> cheers
>>> stefan
>>>
>>> --
>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>> Deploy New Relic app performance management and know exactly
>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>> http://p.sf.net/sfu/newrelic-dev2dev
>>> ___
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>
>>>
>>
>> --
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
> --
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2221 / Virus Database: 2441/5309 - Release Date: 10/04/12
>
>
>


--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know e

Re: [JPP-Devel] Fwd: [jump-pilot - OpenJUMP Functions Problems] SLD export not compatible with GeoServer?

[Martin Davis]

In GeoServer it is possible to filter on geometry type, but using a 
platform-specific technique:

http://docs.geoserver.org/stable/en/user/styling/sld-tipstricks/mixed-geometries.html

But I'm not sure it's necessary to filter by type.  The use of a 
PointSymbolizer ensures that every geometry is rendered as a point, and in 
GeoServer at least non-point geometries will be converted to point locations 
using a simple strategy (eg choosing the centroid).



On 8/18/2012 1:43 AM, Michaël Michaud wrote:
> Hi,
>
> sld:Name location is easy to change (done on my local repository)
>
> oj:dummy can also be removed (don't know if it can break something,
> for deegree users but we must try it)
>
> Wonder where  does PropertyIsInstanceOf come from and if there is
> a valid way to filter according to the geometry type, or it this filter is
>
> useless in a GeoServer context.
>
>


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Fwd: [jump-pilot - OpenJUMP Functions Problems] SLD export not compatible with GeoServer?

[Martin Davis]

I finally had a chance to follow up on this issue by trying it out in 
GeoServer.

There's 3 issues:

- the attribute oj:dummy is invalid
- the predicate PropertyIsInstanceOf at line 13 is not supported in 
GeoServer.  See here for the properties that are supported:

http://docs.geoserver.org/stable/en/user/styling/sld-reference/filters.html

And see this page for a discussion of how to filter by geometry type:

http://docs.geoserver.org/stable/en/user/styling/sld-tipstricks/mixed-geometries.html

- the element  at line 18 is not supported in that location.  
It needs to appear immediately after the  element, as documented here:

http://docs.geoserver.org/stable/en/user/styling/sld-reference/rules.html

HTH - Martin

On 8/11/2012 7:29 AM, Michaël Michaud wrote:
> Hi,
>
> I've not yet geoserver installed to test, but I see 3 problems in the
> error message :
>
> Presence of oj:dummy attribute is probably the main reason for the
> failure (will remove it).
>
> It seems that the Rule/Name element should be placed before the Filter,
> which I also can change.
> (schema-aware parser stop complaining if I change its place)
>
> The  element is used to applies the rule to
> one specific geometry type,
> but I don't now where it comes, if it is valid (it seems it is not) and
> if it is really needed.
>
> Is anyone familiar with geoserver and sld to give a hint and make
> further test ?
>
> Michaël
>
>> The issue appears to be the "oj:dummy" attribute on the initial
>>  element (as the GeoServer message says).
>> The rest of style looks ok by visual inspection.
>>
>> As a first step I would remove that attribute and see if the SLD
>> validates in GeoServer.  And then preventing that attribute from being
>> emitted seems like it should be something that's easy to fix in the code.
>>
>>
>> On 7/20/2012 7:55 AM, Stefan Steiniger wrote:
>>> Hi all,
>>>
>>> anyone experience with geoserver and can recommend anything?
>>> Or has time to fix the SLD?
>>>
>>> cheers,
>>> stefan
>>>
>>>  Original-Nachricht 
>>> Betreff: [jump-pilot - OpenJUMP Functions Problems] SLD export not
>>> compatible with GeoServer?
>>> Datum: Fri, 20 Jul 2012 06:17:39 -0700
>>> Von: SourceForge.net 
>>> An: SourceForge.net 
>>>
>>>
>>> Read and respond to this message at:
>>> https://sourceforge.net/projects/jump-pilot/forums/forum/729479/topic/5456685
>>> By: baptwo
>>>
>>> Hi all,
>>>
>>> I have a problem that you may help me to solve.
>>>
>>> I would like to custom the symbology of  layers into OpenJump and export the
>>> sld and create a new style into geoserver..
>>>
>>> But i made several test and it s always failing :(
>>> Does the sld generated are incompatible with GeoServer?
>>>
>>> i opened a Point shapefile where i set the symbology Square,red.
>>>
>>> SLD file generated by OpenJump =[url]http://cjoint.com/?BGupoFc2eWm[/url]
>>>
>>> This is the error generated by GeoServer when parsing the sld
>>> [url]   http://cjoint.com/?BGuppPkvCYa[/url]
>>>
>>> Sorry I was oblige to post the sld and the geoserver error as link otherwise
>>> the forum categorize it as spam :(
>>>
>>> Thanks for your help.
>>>
>>> Baptiste
>>>
>>> _
>>> You are receiving this email because you elected to monitor this topic
>>> or entire forum.
>>> To stop monitoring this topic visit:
>>> https://sourceforge.net/projects/jump-pilot/forums/forum/729479/topic/5456685/unmonitor
>>> To stop monitoring this forum visit:
>>> https://sourceforge.net/projects/jump-pilot/forums/forum/729479/unmonitor
>>>
>>>
>>>
>>> --
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> ___
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>
>>>
>>> -
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2012.0.2196 / Virus Database: 2437/5142 - Release Date: 07/19/12
>>>
>>>
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Fwd: [jump-pilot - OpenJUMP Functions Problems] SLD export not compatible with GeoServer?

[Martin Davis]

The issue appears to be the "oj:dummy" attribute on the initial 
 element (as the GeoServer message says).  
The rest of style looks ok by visual inspection.

As a first step I would remove that attribute and see if the SLD 
validates in GeoServer.  And then preventing that attribute from being 
emitted seems like it should be something that's easy to fix in the code.


On 7/20/2012 7:55 AM, Stefan Steiniger wrote:
> Hi all,
>
> anyone experience with geoserver and can recommend anything?
> Or has time to fix the SLD?
>
> cheers,
> stefan
>
>  Original-Nachricht 
> Betreff: [jump-pilot - OpenJUMP Functions Problems] SLD export not
> compatible with GeoServer?
> Datum: Fri, 20 Jul 2012 06:17:39 -0700
> Von: SourceForge.net 
> An: SourceForge.net 
>
>
> Read and respond to this message at:
> https://sourceforge.net/projects/jump-pilot/forums/forum/729479/topic/5456685
> By: baptwo
>
> Hi all,
>
> I have a problem that you may help me to solve.
>
> I would like to custom the symbology of  layers into OpenJump and export the
> sld and create a new style into geoserver..
>
> But i made several test and it s always failing :(
> Does the sld generated are incompatible with GeoServer?
>
> i opened a Point shapefile where i set the symbology Square,red.
>
> SLD file generated by OpenJump =[url]http://cjoint.com/?BGupoFc2eWm[/url]
>
> This is the error generated by GeoServer when parsing the sld
>   [url]   http://cjoint.com/?BGuppPkvCYa[/url]
>
> Sorry I was oblige to post the sld and the geoserver error as link otherwise
> the forum categorize it as spam :(
>
> Thanks for your help.
>
> Baptiste
>
> _
> You are receiving this email because you elected to monitor this topic
> or entire forum.
> To stop monitoring this topic visit:
> https://sourceforge.net/projects/jump-pilot/forums/forum/729479/topic/5456685/unmonitor
> To stop monitoring this forum visit:
> https://sourceforge.net/projects/jump-pilot/forums/forum/729479/unmonitor
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2196 / Virus Database: 2437/5142 - Release Date: 07/19/12
>
>



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] [gdal-dev] Re: Performance of reading large polygons with holes

[Martin Davis]

You're right, Even, I was working with a different version of the file.  
The dataset must have changed in the past few days.  I now get the same 
result for MAX(area) that you're getting.

I now get about 60 s for both OGR and JEQL.  Not sure why the new file 
takes so much longer - it's actually smaller than the one I was using.  
Could be fun trying to track this down...

I'd say one thing, though - you must have a fast C compiler, and a slow 
Java implementation!Over 8 min for the JEQL script seems awfully 
slow.  Your box is beefier than mine (mine is pretty old - 2 GHz, dual 
core, 2 GB RAM).  Possibly 64-bit makes a difference?

On 4/22/2012 5:12 AM, Even Rouault wrote:
>> Hi,
>>
>> Ok, this is interesting for several reasons :
>>
>> 1) Trying to run the 'ogrinfo -sql "select max(OGR_GEOM_AREA) from tpi_1"
>> tpi_1.shp' showed that a badly written optimization in OGR 1.9.0 broke such
>> a query. Now fixed per http://trac.osgeo.org/gdal/ticket/4633
>>
>> 2) Width GDAL trunk, 1.9, 1.8 and 1.7, I never get Martin's result. I
>> always get :
>>
>>MAX_OGR_GEOM_AREA (Real) = 70726589354.8597
>>
>> Reached on shape index = 289 (first shape is index = 0):
>>
>> OGRFeature(tpi_1):289
>>id (Real) = 904743.000
>>gridcode (Real) = 4.000
>>class_name (String) = Plains or Open Slopes
>>
>> I though it could come from a compiler issue, but I get the same results
>> with GCC 4.4.3 in debug and optimized mode,  and also with MSVC 2008
>>
>> 3) This runs in about ~ 5 seconds on all those versions on my machine
>> (after several runs so that the I/O cache is hot)
>>
>> OS: Ubuntu 10.04 64bit
>> CPU : Intel(R) Core(TM) i5 CPU 750  @ 2.67GHz
>> RAM : 4 GB
> I've just tried with http://tsusiatsoftware.net/jeql/files/jeql-0.11.zip and I
> get the following results :
>
> time java -cp commons-
> lang-2.6.jar:h2.jar:javaproj-1.0.6.jar:jcommon-1.0.16.jar:jeql-0.11.jar:jfreechart-1.0.13.jar:jts-1.12.jar:jtsio-1.12.jar:proj4j-0.1.0.jar:stax2-2.1.jar:stax-
> api-1.0.1.jar:wstx-lgpl-3.2.7.jar -Xms256M -Xmx1024M jeql.JeqlCmd script.jql
> col0:Double
> 70726589354,85522
>
> real  8m30.478s
> user  8m29.480s
> sys   0m0.530s
>
> I've also inserted that shape into a Spatialite and PostGIS DB and they also
> return very close areas with their ST_Area() implementation.
>
> So I'm not sure that Martin and I are working on the same shapefile...
>
> Here is mine :
>
> -rw-r--r--   1 even even  322589721 2012-04-21 06:52 tpi_1.dbf
> -rw-r--r--   1 even even893 2012-04-21 07:03 tpi_1.prj
> -rw-r--r--   1 even even  389028108 2012-04-21 06:53 tpi_1.shp
> -rw-r--r--   1 even even8039716 2012-04-21 06:52 tpi_1.shx
>
> $ md5sum tpi_1.shp
> c50c502cae5b172e270dc02e8562c69c  tpi_1.shp
>
>
>> Best regards,
>>
>> Even
>> ___
>> gdal-dev mailing list
>> gdal-...@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1913 / Virus Database: 2411/4952 - Release Date: 04/22/12
>
>

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Performance issue with large polygons with holes in ShapefileReader

[Martin Davis]

Since the claimed 4 s for OGR seems suspiciously fast, I played around 
with some scenarios intended to ensure that OGR was actually reading and 
constructing every geometry.  I eventually settle on computing the 
maximum area of the polygons, since this was the simplest query I could 
come up with that would guarantee building the polygons.  On the Java 
side I used JEQL, since I could easily replicate this query, it's using 
more or less the same shapefile code as OJ, and it was the source of the 
32 s number I gave earlier.

The result suprised me:  OGR: ~40s, JEQL ~20s.

The details, in case anyone wants to retry this:

OGR:

ogrinfo -sql "select max(OGR_GEOM_AREA) from tpi_1" tpi_1.shp

Result:max_OGR_GEOM_AREA (Real) = 68476900073.166

JEQL:

ShapefileReader t file: "tpi_1.shp";
t = select max(Geom.area(GEOMETRY)) from t;
Print t;

Result:

col0:Double
68476900073.13647
Run completed in 19.015 s

(Good to see that the areas are within 0.03 m^2!)

So either the OGR area routine is slow, or else the reader is pretty 
smart and only builds geometries when it really has to.  On the JEQL 
side, the read time of 32 s I quoted before was actually based on a 
query which was computing the maximum number of points in the geometries 
(again, to force reading the geometries, since JEQL uses lazy 
evaluation). So for some reason counting the max number of points is 
slow, which is peculiar. More research required to track down why that 
is.  But I think the area-based result is valid.


On 4/21/2012 5:26 AM, Rahkonen Jukka wrote:
> Hi,
>
> I asked how GDAL/OGR performs from the gdal-dev list. Discussion follows.
>
> From: Rahkonen Jukka  mmmtike.fi>
> Subject: Re: Performance of reading large polygons with 
> holes<http://news.gmane.org/find-root.php?message_id=%3c84446DEF76453C439E9E97E438E13A6314B135%40suutari.haapa.mmm.fi%3e>
> Newsgroups: 
> gmane.comp.gis.gdal.devel<http://news.gmane.org/gmane.comp.gis.gdal.devel>
> Date: 2012-04-21 12:24:06 GMT ( ago)
>
> Even Rouault wrote:
>
>> Le samedi 21 avril 2012 12:41:49, Jukka Rahkonen a écrit :
>>> Hi,
>>>
>>> Martin Davis started this thread on OpenJUMP-dev list
>>> http://thread.gmane.org/gmane.comp.gis.jump.devel/9
>>> Perhaps someone would like to test how OGR performs with such data?
>>> Link to dataset is mentioned in the discussion.
>> I suppose that dataset you mention is :
>> http://maps.cmparks.net/geoserver/metroparks/ows?service=WFS&version=1.0.0&request=GetFeature&;>typeName=metroparks:tpi_1&outputFormat=SHAPE-
> ZIP ?
>
> Exactly.
>
>> If so, on my box, the whole shapefile (~ 390 MB for the .shp / ~1 million
>> features) can be read in about 4 seconds with a simplified version of ogrinfo
>> that just loops on all the features. The algorithm that assembles the rings 
>> of
>> polygon shapes into polygons that conform to Simple Features has been pretty
>> improved during the last years. It is in the
>> OGRGeometryFactory::organizePolygons() method ( see
>> http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrgeometryfactory.cpp#L1015
>> ) . For shapefiles, there's a shortcut that save a lot of computations w.r.t.
>> the general algorithm, because the shapefile specification states that outer
>> rings should be described clockwise , whereas inner rings should be described
>> counter-clockwise.
>

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Performance issue with large polygons with holes in ShapefileReader

[Martin Davis]

As long as there aren't too many shells, it's ok to use a linear search, 
isn't it?

Did you confirm that OGR is actually reading and forming the 
geometries?  I still find it hard to believe that it can read the geoms 
in only 4 s!

It's interesting about the envelope computation.  In JTS these are 
computed lazily, but in the ShapefileReader they're used right away to 
test for candidate shells for holes.

On 4/21/2012 10:42 AM, Michaël Michaud wrote:
> Hi,
>
> Oh yes, the short circuit will not improve performance much in our case
> because most often, the equalsExact will also be performed.
> (I don't think equalsExact should be removed as it could break
> algorithms relying on it)
>
> Maybe the good structure would have been to map shells to hole lists
> with a IdentityHashMap ?
>
> I did some profiling to try to understand the difference between our
> reader and OGR's
> and found that most of the time in PolygonHandler was spent in Envelope
> computation
>
> I think envelope are required to display data efficiently,
> but I could not find where exactly they were computed
> (tried to deactivate envelope computation everywhere in FeatureDataset
> without performance gain).
>
> I also found that we missed a test for the single-ring case (where ccw
> computation
> can be avoided), but there is not much difference at the end.
>
> Michaël
>> Oh - except that in the cases where the geometries are *not* identical,
>> then a slower equals test is performed.  So still better to just test
>> reference equality, I think.
>>
>> On 4/21/2012 8:05 AM, Martin Davis wrote:
>>> That does seem like a good idea.  I'll look at adding that.
>>>
>>> On 4/21/2012 12:48 AM, Michaël Michaud wrote:
>>>> Implementing #3 I was wondering why not implementing the following
>>>> short circuit in Geometry equals method
>>>> public boolean equals(Object o) {
>>>>if (this == o) return true;
>>>>etc.
>>>> }
>>>> Can you see any drawback ?
>>>> Seems that this way, many algorithms could automatically benefit your
>>>> #3 trick.
>>>>
>>>>
>>> --
>>> For Developers, A Lot Can Happen In A Second.
>>> Boundary is the first to Know...and Tell You.
>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>> ___
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>
>>>
>>> -
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2012.0.1913 / Virus Database: 2411/4950 - Release Date: 04/21/12
>>>
>>>
>>>
>> --
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>>
>
> --
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1913 / Virus Database: 2411/4950 - Release Date: 04/21/12
>
>
>

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Performance issue with large polygons with holes in ShapefileReader

[Martin Davis]

Oh - except that in the cases where the geometries are *not* identical, 
then a slower equals test is performed.  So still better to just test 
reference equality, I think.

On 4/21/2012 8:05 AM, Martin Davis wrote:
> That does seem like a good idea.  I'll look at adding that.
>
> On 4/21/2012 12:48 AM, Michaël Michaud wrote:
>>
>> Implementing #3 I was wondering why not implementing the following
>> short circuit in Geometry equals method
>> public boolean equals(Object o) {
>>  if (this == o) return true;
>>  etc.
>> }
>> Can you see any drawback ?
>> Seems that this way, many algorithms could automatically benefit your
>> #3 trick.
>>
>>
>
> --
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1913 / Virus Database: 2411/4950 - Release Date: 04/21/12
>
>
>

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Performance issue with large polygons with holes in ShapefileReader

[Martin Davis]

That does seem like a good idea.  I'll look at adding that.

On 4/21/2012 12:48 AM, Michaël Michaud wrote:
>
>
> Implementing #3 I was wondering why not implementing the following 
> short circuit in Geometry equals method
> public boolean equals(Object o) {
> if (this == o) return true;
> etc.
> }
> Can you see any drawback ?
> Seems that this way, many algorithms could automatically benefit your 
> #3 trick.
>
>


--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Performance issue with large polygons with holes in ShapefileReader

[Martin Davis]

Wow, that's quite a difference.  I wonder what they're doing differently?

It might be that C reading of binary data is much faster than Java 
(because of the wierd endian issues in Shapefiles, there's a lot of 
computation needed just to read the file).


And I wonder if ogrinfo is actually assembling the geometries, or if 
it's just reading headers or counting geometries?


On 4/21/2012 5:26 AM, Rahkonen Jukka wrote:

Hi,

I asked how GDAL/OGR performs from the gdal-dev list. Discussion follows.

From: Rahkonen Jukka  mmmtike.fi>
Subject: Re: Performance of reading large polygons with 
holes<http://news.gmane.org/find-root.php?message_id=%3c84446DEF76453C439E9E97E438E13A6314B135%40suutari.haapa.mmm.fi%3e>
Newsgroups: 
gmane.comp.gis.gdal.devel<http://news.gmane.org/gmane.comp.gis.gdal.devel>
Date: 2012-04-21 12:24:06 GMT ( ago)

Even Rouault wrote:


Le samedi 21 avril 2012 12:41:49, Jukka Rahkonen a écrit :

Hi,

Martin Davis started this thread on OpenJUMP-dev list
http://thread.gmane.org/gmane.comp.gis.jump.devel/9
Perhaps someone would like to test how OGR performs with such data?
Link to dataset is mentioned in the discussion.

I suppose that dataset you mention is :
http://maps.cmparks.net/geoserver/metroparks/ows?service=WFS&version=1.0.0&request=GetFeature&;>typeName=metroparks:tpi_1&outputFormat=SHAPE-

ZIP ?

Exactly.


If so, on my box, the whole shapefile (~ 390 MB for the .shp / ~1 million
features) can be read in about 4 seconds with a simplified version of ogrinfo
that just loops on all the features. The algorithm that assembles the rings of
polygon shapes into polygons that conform to Simple Features has been pretty
improved during the last years. It is in the
OGRGeometryFactory::organizePolygons() method ( see
http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrgeometryfactory.cpp#L1015
) . For shapefiles, there's a shortcut that save a lot of computations w.r.t.
the general algorithm, because the shapefile specification states that outer
rings should be described clockwise , whereas inner rings should be described
counter-clockwise.

Thus it is 4 seconds vs. 32 seconds measured by Martin. It is a considerable 
difference but perhaps Martin is
not doing exactly the same thing.  Anyway, speed of OGR seems to be excellent.

-Jukka Rahkonen-



Lähettäjä: Michaël Michaud [michael.mich...@free.fr]
Lähetetty: 21. huhtikuuta 2012 12:19
Vastaanottaja: jump-pilot-devel@lists.sourceforge.net
Aihe: Re: [JPP-Devel] Performance issue with large polygons with holes in 
ShapefileReader

Hi,

Sorry for the bad example :
In the illustration, the medium shell does not pass the PiP test,
so it is never considered as a possible candidate.

After many useless tries to find a case where this test did not work,
I tried to understand why it works.

Finally, that's how I explain it :
if one consider the geometry as valid  :
If a hole h is included in 2 shells s1 and s2,
==>  s1 and s2 are overlaping in h
==>  as the multigeometry is valid ==>  s1 (resp s2) shoul be entirely in a 
hole of s2 (resp s1)
==>  s1 envelope (resp s2 envelope) is included in s2 envelope (resp s1 
envelope)
==>  h is in a polygon which in turn is in the hole of another polygon,
   it must be associated to the inner one (the one with the smallest 
envelope)

Sorry for the noise, especially if the result was obvious for you, guys,
it was certainly not for me ;-)

Michaël

About the #2, I think the test currently done in OpenJUMP is wrong
In case where several shell's ebvelope contain hole's envelope, if shells are
included in each other, the hole is associated to the smallest :
if (shellEnvelope.contains(holeEnvelope)&&
 (minShellEnv == null || minShellEnv.contains(shellEnvelope))&&
 (cga.isPointInRing(testPt,coordList ))) {
 minShellEnv = shellEnvelope;
}

I think it will not work in this case :

[cid:part1.01040602.00090309@free.fr]

I'll measure the penalty if the second test is removed
and eventually, I'll try to implement Martin's #2 tip.

Michaël






Le 21/04/2012 06:03, Martin Davis a écrit :
The file I sent is in Ohio, I think.  It was sent to me by Stephen Mather, who 
I met in Washington DC at FOSS4GNA last week.  It's pretty excessive - not the 
normal kind of shapefile, I think.  But still, it's nice to optimize the corner 
cases, especially if they take 10x longer to run.

I did realize that the use case for GeoTools (in GeoServer at least) is a bit 
different to OJ.  GeoServer doesn't cache data in memory, so it's going to be 
reading data many times, so every second is precious.  And there's no 
expectation it will fix bad data - it just has to provide something that 
mirrors what was read.  OJ on the other hand might be expected to try to fix 
some of the bad data, and users might be willing to spend more time on load t

Re: [JPP-Devel] Performance issue with large polygons with holes in ShapefileReader

[Martin Davis]

The file I sent is in Ohio, I think.  It was sent to me by Stephen 
Mather, who I met in Washington DC at FOSS4GNA last week.  It's pretty 
excessive - not the normal kind of shapefile, I think.  But still, it's 
nice to optimize the corner cases, especially if they take 10x longer to 
run.


I did realize that the use case for GeoTools (in GeoServer at least) is 
a bit different to OJ.  GeoServer doesn't cache data in memory, so it's 
going to be reading data many times, so every second is precious.  And 
there's no expectation it will fix bad data - it just has to provide 
something that mirrors what was read.  OJ on the other hand might be 
expected to try to fix some of the bad data, and users might be willing 
to spend more time on load to get that functionality.


Anyway, fix #3 is good in any case, and it seems like a good thing that 
you added fix #1 too.  Fix #2 was a bit more speculative, and it only 
applies in very specific circumstances, so it's probably not as 
critical.  (BTW, the idea was not to assume to which shell holes were 
assigned to, but to check if only one shell could actually contain a 
given hole, by virtue of the envelope intersection test).


On 4/20/2012 11:02 AM, Michaël Michaud wrote:

Martin,

Thanks for the file, very impressive (did not guess where it was - but 
only searched in Canada).


You convinced me.
We had two previous discussions on the list about preserving weird 
shapefile as much as possible,

but none of them was about holes lying out of their shell.

So let's go where geotools already is.
I had a quick look on your suggestion #2, but could not see a way to 
improve.
For more than one shell case, we don't know which hole is associated 
with which shell before the test
(except if we assume that the description of a shell is immediately 
followed by the description of its holes)

Don't know if we should assume this.

For "more than one shell" case, I just changed the order of tests to 
do a bit more envelope tests and a bit less PiP tests but I could not 
measure the difference on your file.


Michaël



Very thorough investigation, Michael.

The shapefile I was using is here:

http://maps.cmparks.net/geoserver/metroparks/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=metroparks:tpi_1&outputFormat=SHAPE-ZIP

(   http://tinyurl.com/c9k26gp  )
It is pretty gnarly - over 1M polygons, and has the following stats 
for the largest (vertices/holes):


18527 1112
58597 5526
31087 1598
24152 1318
17989 1386
20280 1098
20815 1336
44871 1204
61496 3024
28370 1120
46058 2156
21970 1546
91379 3034
121028 8012
81172 4544
28544 1272
20524 1074
6 1992
2282758 169278
1166731 94382
241350 14250
142028 5922
139035 5690
33610 1344
83112 3134
38464 1048

GeoTools has had optimization #1 for quite a while, I think, if 
that's any reassurance.


On 4/20/2012 6:29 AM, Michaël Michaud wrote:

Hi,

Here are some test cases done with a 200 Mb shapefile (thanks Jukka)
containing : 221770 polygons
worst case : 287273 pts and 5484 holes

Dataset : Current OJ code / 1st Martin's optimization / 3rd Martin's 
optimization / 1st+3rd

whole shapefile : 41 s / 24 s / 24 s / 11 s
worst polygon : 4.6 s / 0.16 s / 3.3 s / 0.13 s

==>
1st optimization has a big impact on worst case and a medium impact 
on a whole file with mixed cases
3rd optimization has a small impact on worst case and a medium 
impact on a whole file with mixed cases


I'll commit the 3rd optimization anyway has it has no side effect.
For the 1st one, i'll try to check if it may have negative impact on 
some shapefile (if I can find or produce such shapefiles)






--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2


___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel




--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2


___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


No virus found in this message.
Checked by AVG - www.avg.com 
Version: 2012.0.1913 / Virus Database: 2411/4948 - Release Date: 04/20/12

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2___

[JPP-Devel] Performance issue with large polygons with holes in ShapefileReader

[Martin Davis]

Recently I've been working with a dataset which has many large polygons 
with many holes (eg 100K+ vertices, 1000+ holes).  This revealed a 
performance issue with the Shapefile reading code that I'm using, which 
is pretty much the same as the code in JUMP (and is descended from an 
old GeoTools version).  The issue is that the point-in-polygon test is 
fairly slow when run against large shells and for many holes.

There's a few fixes required:
1. if only one shell is present, do not run the PIP code, but simply 
assign the holes to the shell.  (This fix has been made in the current 
GeoTools PolygonHandler code, and could be copied from there)
2. this can be extended to checking for only one *candidate* shell (a 
candidate shell is one whose envelope contains the hole envelope).  This 
code is not yet developed.
3. the code uses ArrayList.indexOf.  This is inefficient, since it uses 
equals(), which does a full equality comparison.  Instead, an iterator 
and == should be used instead  (code below)

The performance improvement from just #1 was dramatic - reading a 1M 
feature shapefile went from over 1000 s to 32 s.



PolygonHandler change:

 ((ArrayList) holesForShells.get(findIndex(shells, 
minShell))).add(testHole);


   /**
* Finds a object in a list. Should be much faster than indexof
*
* @param list
* @param o
* @return
*/
   private static int findIndex(ArrayList list, Object o)
   {
 int n = list.size();
 for (int i = 0; i < n; i++) {
   if (list.get(i) == o)
 return i;
 }
 return -1;
   }



--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Decimation for improving rendering performance?

[Martin Davis]

On 2/18/2012 11:32 AM, Michaël Michaud wrote:
> Hi Martin,
>> Does OJ use decimation to help improve rendering performance?  I know
>> this wasn't in JUMP, but perhaps it's been added?
> Thanks to Larry Becker, we've had this kind of decimation for a few years.
Oh, great.  I'll have a look at the code.
>
> It has been a great improvement in the rendering system.
>
> I did a new addition last year to display efficiently huge geometries.
> Displaying a linestring with several hundred thousand points was still
> slow at scales were scale-based decimation was not active.
> I removed segments which were not intersecting the window from
> the rendering pipeline (even easier than the scale-base decimation).
Yes, it's always easier to deal with LineStrings!
>
> But there is still no optimization for huge polygons display. I have no
> other idea than a strict clipping of the polygon on the window (with
> JTS intersection) which is a more heavy operation. I think it is not
> worthwhile, but I may be wrong (it's already used for labelling display)
I've thought about this as well.  I did experiment a bit with developing 
a faster clipping algorithm using rectangles (since clipping against a 
rectangle should be able to produce a faster, simpler, robust 
algorithm).  But I haven't had the chance to complete this work.  I also 
wonder whether another approach is possible to drastically simplify the 
portion of the polygon outside the viewport in some way (obviously 
checking to ensure that the visible topology is not affected).
>
> Multi-geometries display could also be optimized based on the
> envelop of their simple geometries, but I still did not do this
> optimization.
>
> Thanks, your suggestion are always welcome,
>
> Michaël
>
>> If not, it's worth having a look at - it's fairly easy to implement, and
>> it makes a big difference in rendering speed.  I've just added
>> decimation capability to the JTS ShapeWriter class - this can provide a
>> model to follow (or maybe even be used directly).
>>
>> http://jts-topo-suite.svn.sourceforge.net/viewvc/jts-topo-suite/trunk/jts/java/src/com/vividsolutions/jts/awt/ShapeWriter.java?revision=545&view=markup
>>
>> Martin
>>
>> --
>> Virtualization&   Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>>
>
> --
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1913 / Virus Database: 2112/4817 - Release Date: 02/18/12
>
>
>

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] Decimation for improving rendering performance?

[Martin Davis]

Hey, list...

Does OJ use decimation to help improve rendering performance?  I know 
this wasn't in JUMP, but perhaps it's been added?

If not, it's worth having a look at - it's fairly easy to implement, and 
it makes a big difference in rendering speed.  I've just added 
decimation capability to the JTS ShapeWriter class - this can provide a 
model to follow (or maybe even be used directly).

http://jts-topo-suite.svn.sourceforge.net/viewvc/jts-topo-suite/trunk/jts/java/src/com/vividsolutions/jts/awt/ShapeWriter.java?revision=545&view=markup

Martin

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] good news and congrats to Martin

[Martin Davis]

Interesting idea...

My impression is that OpenGeo prefers thin, web-based clients where 
possible. But as you point out, there are some significant limitations 
with this approach when used with large volumes of vector data.  It does 
seem like it would be a good thing to have a richer client which can 
really show off the performance capabilities of GeoServer.

Another thing which seems to be something a lot of people want is a good 
SLD style editor.  I have heard that uDig is useful for this (which 
makes sense, since it's based on GeoTools).   I think OpenGeo's 
direction is the Styler GeoExt app - but there's probably room for more, 
and a rich client app would probably have some nice capabilities which 
are harder to do on the web.

Anyway, it will be a while before I am in a position to influence 
OpenGeo direction!

Martin

On 10/26/2011 9:56 PM, Rahkonen Jukka wrote:
> Hi,
>
> Half seriously, let's see it OpenGEO now sees the potential and benefit of 
> making OpenJUMP to a full compliant WFS client supporting all the fine 
> Geoserver WFS features and includes OpenJUMP into the Geoserver installation 
> package (or into OpenGEO Suite) which now has an OpenLayers demo client and 
> new users keep asking why does it not show more than 150 WFS features in the 
> WFS layer preview.  OpenJUMP could also a nice client for new WPS processes. 
> Yes, and INSPIRE download services which are WFS with some extras.
> Unfortunately nobody maintains now the deegree based WFS client and fixing it 
> would probably mean building a new one based on Geotools and for that a 
> sponsor would be needed.
>
> -Jukka Rahkonen-
>
> Stefan Steiniger wrote:
>
>> Hi All,
>> the architect/designer of JUMP/OpenJUMP stays well integrated with the
> FOSS4G family:
>
>> http://opengeo.org/about/press/20111025-martindavis/
> congrats and best of luck for you Martin!
>
> stefan
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1834 / Virus Database: 2092/4575 - Release Date: 10/26/11
>
>

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] good news and congrats to Martin

[Martin Davis]

Thanks, Stefan.  It's great to be more closely involved with the cutting 
edge of open source geospatial software.

Martin

On 10/26/2011 9:52 AM, Stefan Steiniger wrote:
> Hi All,
>
> the architect/designer of JUMP/OpenJUMP stays well integrated with the
> FOSS4G family:
>
> http://opengeo.org/about/press/20111025-martindavis/
>
> congrats and best of luck for you Martin!
>
> stefan
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1834 / Virus Database: 2092/4575 - Release Date: 10/26/11
>
>

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] include isa, link igor

[Martin Davis]

Ok, makes sense. I didn't realize that GeoTools was already available 
for CRS transformations.

On 10/19/2011 2:36 AM, edgar.sol...@web.de wrote:
> this was considered, but as geotools seemed to be better maintained when we 
> discussed this a long time ago, we thought that this would be the way to go.
> also the cts extension already uses geotools, although a very old version.
>
>
> ..ede
>
> On 19.10.2011 00:24, Martin Davis wrote:
>> If there is a need for reprojection in OpenJUMP, has anyone looked at
>> adding a plugin using Proj4J?
>>
>> http://trac.osgeo.org/proj4j/
>>
>>
>> On 10/18/2011 2:43 PM, Rahkonen Jukka wrote:
>>> Hi,
>>>
>>> SkyJUMP with igor is doing conversion with ogr2ogr.exe located at 
>>> \SkyJUMP\Jump\bin\ogr\bin with a bunch of dll's.  They have been captured 
>>> from the FWTools delivery. Ogr2ogr is using the included Proj4 for 
>>> coordinate transformations.  System works well but it is for Windows only 
>>> and does not necessarily suit well with the philosophy of OpenJUMP.
>>>
>>> -Jukka Rahkonen-
>>> 
>>> Lähettäjä: Michaël Michaud [michael.mich...@free.fr]
>>> Lähetetty: 19. lokakuuta 2011 0:06
>>> Vastaanottaja: OpenJump develop and use
>>> Aihe: Re: [JPP-Devel] include isa, link igor
>>>
>>> Hi,
>>>> could you add a note on the wiki plugin page under "coordinate 
>>>> transformation"?
>>> OK, I'll add a note on wiki (but I'll need to make some more test before)
>>>> and porting the SkyJUMP
>>>> PlugIn (if any) to OpenJUMP is probably a good idea to make it available
>>>> to OpenJUMP users.
>>>> could you summarize in short what the plugin does?
>>> If I remember correctly, Igor is basically a java interface which runs
>>> ogr2ogr tool, a command line tool written in C(++ ?) and able to
>>> transform datasets from a format to another and from a CRS to another
>>> (last one is based on proj4).
>>>>> As jukka, I would delay an inclusion in OpenJUMP PLUS
>>>>> - take time for testing, internationalization, maybe updating
>>>>> - take time to compare a OpenJUMP + GeoTools formula with a OpenJUMP +
>>>>> ogr + proj4 formula
>>>> the inclusion was targetted towards the kml file source. any comment on 
>>>> that?
>>> Igor does much more than kml. There is also a small kml pure java plugin
>>> in SkyJUMP (I have tested it on OpenJUMP a few weeks ago), but Igor is a
>>> tool which can be used without *JUMP, and which gives access to a
>>> powerfull transformation tool.
>>>
>>> Michaël
>>>> ..ede
>>>>
>>>>> Michaël
>>>>>
>>>>> Le 18/10/2011 13:59, Rahkonen Jukka a écrit :
>>>>>> Hi,
>>>>>>
>>>>>> Plugins included into the OpenJUMP+ should be generally interesting and 
>>>>>> if the KML extension is such then why not. I would say that the + 
>>>>>> plugins should be tested to be about as reliable as the core OJ. 
>>>>>> Seldomly used and experimental plugins can be installed separately. We 
>>>>>> might be better with the plugins. Now some of them are hard to find and 
>>>>>> not so friendly to install. Quantum GIS has perhaps the most user 
>>>>>> friendly plugin manager.
>>>>>>
>>>>>> Igor is worth mentioning and it could be mentioned also that it is 
>>>>>> integrated with SkyJUMP so that SkyJUMP can open all vector formats 
>>>>>> supported by ogr. Or most formats at least. SkyJUMP is doing an interim 
>>>>>> convertion into shapefiles with igor first and then opens the shapefile 
>>>>>> automatically if user wants so. Not all format can be converted into 
>>>>>> shapefiles without loosing or altering some data but usually SkyJUMP 
>>>>>> with igor is doing good work.
>>>>>>
>>>>>> -Jukka Rahkonen-
>>>>>>
>>>>>> edgar.soldin wrote:
>>>>>>
>>>>>>> i am in contact with a german user who's english is virtually
>>>>>>> not existing. he suggested to
>>>>>>>
>>>>>>> A) include isa plugin's capability to read(write?) kml files
>>>>>>> in sextante(plus) edition
>>>>>>>

Re: [JPP-Devel] include isa, link igor

[Martin Davis]

If there is a need for reprojection in OpenJUMP, has anyone looked at 
adding a plugin using Proj4J?

http://trac.osgeo.org/proj4j/


On 10/18/2011 2:43 PM, Rahkonen Jukka wrote:
> Hi,
>
> SkyJUMP with igor is doing conversion with ogr2ogr.exe located at 
> \SkyJUMP\Jump\bin\ogr\bin with a bunch of dll's.  They have been captured 
> from the FWTools delivery. Ogr2ogr is using the included Proj4 for coordinate 
> transformations.  System works well but it is for Windows only and does not 
> necessarily suit well with the philosophy of OpenJUMP.
>
> -Jukka Rahkonen-
> 
> Lähettäjä: Michaël Michaud [michael.mich...@free.fr]
> Lähetetty: 19. lokakuuta 2011 0:06
> Vastaanottaja: OpenJump develop and use
> Aihe: Re: [JPP-Devel] include isa, link igor
>
> Hi,
>> could you add a note on the wiki plugin page under "coordinate 
>> transformation"?
> OK, I'll add a note on wiki (but I'll need to make some more test before)
>> and porting the SkyJUMP
>> PlugIn (if any) to OpenJUMP is probably a good idea to make it available
>> to OpenJUMP users.
>> could you summarize in short what the plugin does?
> If I remember correctly, Igor is basically a java interface which runs
> ogr2ogr tool, a command line tool written in C(++ ?) and able to
> transform datasets from a format to another and from a CRS to another
> (last one is based on proj4).
>>> As jukka, I would delay an inclusion in OpenJUMP PLUS
>>> - take time for testing, internationalization, maybe updating
>>> - take time to compare a OpenJUMP + GeoTools formula with a OpenJUMP +
>>> ogr + proj4 formula
>> the inclusion was targetted towards the kml file source. any comment on that?
> Igor does much more than kml. There is also a small kml pure java plugin
> in SkyJUMP (I have tested it on OpenJUMP a few weeks ago), but Igor is a
> tool which can be used without *JUMP, and which gives access to a
> powerfull transformation tool.
>
> Michaël
>> ..ede
>>
>>> Michaël
>>>
>>> Le 18/10/2011 13:59, Rahkonen Jukka a écrit :
 Hi,

 Plugins included into the OpenJUMP+ should be generally interesting and if 
 the KML extension is such then why not. I would say that the + plugins 
 should be tested to be about as reliable as the core OJ. Seldomly used and 
 experimental plugins can be installed separately. We might be better with 
 the plugins. Now some of them are hard to find and not so friendly to 
 install. Quantum GIS has perhaps the most user friendly plugin manager.

 Igor is worth mentioning and it could be mentioned also that it is 
 integrated with SkyJUMP so that SkyJUMP can open all vector formats 
 supported by ogr. Or most formats at least. SkyJUMP is doing an interim 
 convertion into shapefiles with igor first and then opens the shapefile 
 automatically if user wants so. Not all format can be converted into 
 shapefiles without loosing or altering some data but usually SkyJUMP with 
 igor is doing good work.

 -Jukka Rahkonen-

 edgar.soldin wrote:

> i am in contact with a german user who's english is virtually
> not existing. he suggested to
>
> A) include isa plugin's capability to read(write?) kml files
> in sextante(plus) edition
>
> B) to mention http://sourceforge.net/projects/ogr-igor/ inour
> docs for people struggling with reprojection
>
> any opinions, ede
>
>
> --
> 
> All the data continuously generated in your IT infrastructure
> contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data
> and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
 --
 All the data continuously generated in your IT infrastructure contains a
 definitive record of customers, application performance, security
 threats, fraudulent activity and more. Splunk takes this data and makes
 sense of it. Business sense. IT sense. Common sense.
 http://p.sf.net/sfu/splunk-d2d-oct
 ___
 Jump-pilot-devel mailing list
 Jump-pilot-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


>>> --
>>> All the data continuously generated in your IT infrastructure contains a
>>> definitive record of customers, application performance, security
>>> threats, fraudulent activity and more. Splunk takes thi

Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone

[Martin Davis]

I think having lots of alternatives is ok...  In one app I use 
(PaintShopPro) there are literally dozens of format options presented in 
the save dropdown.

Martin

On 10/18/2011 5:08 AM, Rahkonen Jukka wrote:
> How would you do the saving into GML with the three native dialects we have 
> (JUMP GML, GML 2.0 with hand written template, and FME GML) or possibly with 
> the fourth GML 2.0 variant if deejump plugin is installed?  If there would be 
> one line on the list for each alternative then the zip check box would be 
> better, otherwise we would need totally six or eight lines for GML save 
> formats.
>
> -Jukka-
>
> edgar.soldin wrote:
>> On 17.10.2011 22:46, Michaël Michaud wrote:
>>> Hi,
>>>> Would an even simpler alternative be to determine the
>> format from the
>>>> extension, where this is unabiguous, and if it is ambiguous or
>>>> undetermined then let the user choose the desired format?
>>> I think such a mechanism exist in the new OpenDialog Framework.
>>> If I'm correct, the double combobox currently appears
>>> 1) in the old openfile dialog (category context menu)
>>> 2) in the save as dialog box
>> i could only find them there too
>>
>>> I'm not sure the first one is still needed (but I think users had
>>> choosen to keep it when we migrated to the new framework)
>> even so, we currently have two ways to open files. how to
>> explain that to new users? better to have one only.
>>
>>> I thing the double dialog is of no use in the save as
>> dialog box where
>>> combinations of format and extension can be defined in a
>> single combobox.
>>> Zip could be a general option however (a checkbox)
>> i wouldn't say no use, but it is counter-intuitive. it would
>> be easy to merge the options into one dropdwon only without a
>> loss in capabilities.
>>
>>>> So examples are:
>>>> - if a .SHP file is chosen, the format is set to Shapefile
>> automatically.
>>>> - if a .ZIP or .XML file is chosen, the user must choose
>> the appropriate
>>>> format
>> for save i'd rather have
>>
>> ESRI (*.shp)
>> ESRI Compressed (*.zip)
>> GML (*.gml)
>> GML Compressed (*.zip)
>> ...
>>
>> or
>>
>> ESRI (*.shp)
>> GML (*.gml)
>> ...
>> and a checkbox that signals zipping enabled
>>
>>
>>> And even zip files could be automatically opened as long as
>> they contain
>>> unambiguous formats.
>> zip and tgz (i think) when opened with OpenFileWizard are
>> automatically scanned for files with known extensions and
>> opened with the appropriate factory.
>>
>>> My 2 cents
>> make it 4, ede
>>
>>> Michaël
>>>>
>>>>
>>>> So there is only one dropdown for Format, and then the checkbox
>>>>
>>>> On 10/14/2011 12:59 AM, edgar.sol...@web.de wrote:
>>>>>> On 10/13/2011 2:24 AM, edgar.sol...@web.de wrote:
>>>>>>> On 13.10.2011 01:02, Martin Davis wrote:
>>>>>>>> One reason for having the double choice of both format
>> and file name is
>>>>>>>> that there are formats (such as GML) which don't have
>> a standard file
>>>>>>>> extension that can be used to drive the choice of format.
>>>>>>>>
>>>>>>>> Also, in JUMP originally we supported a zipped
>> shapefile concept.  It
>>>>>>>> had the extension .zip, but was read by the Shapefile driver.
>>>>>>>>
>>>>>>>> One thing that could be do would be to use the file
>> extension to drive
>>>>>>>> the initial format setting, but allow it to be
>> overridden for files with
>>>>>>>> non-specific extensions.
>>>>>>>>
>>>>>>> How about a checkbox 'filter by extension', which can
>> be disabled allowing to select any file with any selection in
>> the format dropdown?
>>>>>> Ok, but I'm not sure how this solves the problem of
>> determining the
>>>>>> format of a file with an unknown extension?
>>>>>>
>>>>> there is no determination. but, it allows users to assign
>> a format of their choice to a file of their choice and try to open it.
>>>>> seen? ede
>>>>>
>>>>>
>> --
>> ---

Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone

[Martin Davis]

So is the behaviour:

- if Filter By Extension is unchecked, then the user can select any file 
and any format
- if Filter By Extension is checked, then the user selects a file and 
the format is determined from the extension

?

Would an even simpler alternative be to determine the format from the 
extension, where this is unabiguous, and if it is ambiguous or 
undetermined then let the user choose the desired format?

So examples are:
- if a .SHP file is chosen, the format is set to Shapefile automatically.
- if a .ZIP or .XML file is chosen, the user must choose the appropriate 
format



So there is only one dropdown for Format, and then the checkbox

On 10/14/2011 12:59 AM, edgar.sol...@web.de wrote:
>
>> On 10/13/2011 2:24 AM, edgar.sol...@web.de wrote:
>>> On 13.10.2011 01:02, Martin Davis wrote:
>>>> One reason for having the double choice of both format and file name is
>>>> that there are formats (such as GML) which don't have a standard file
>>>> extension that can be used to drive the choice of format.
>>>>
>>>> Also, in JUMP originally we supported a zipped shapefile concept.  It
>>>> had the extension .zip, but was read by the Shapefile driver.
>>>>
>>>> One thing that could be do would be to use the file extension to drive
>>>> the initial format setting, but allow it to be overridden for files with
>>>> non-specific extensions.
>>>>
>>> How about a checkbox 'filter by extension', which can be disabled allowing 
>>> to select any file with any selection in the format dropdown?
>>>
>> Ok, but I'm not sure how this solves the problem of determining the
>> format of a file with an unknown extension?
>>
> there is no determination. but, it allows users to assign a format of their 
> choice to a file of their choice and try to open it.
>
> seen? ede
>
> --
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1410 / Virus Database: 1522/3949 - Release Date: 10/13/11
>
>

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone

[Martin Davis]

Ok, but I'm not sure how this solves the problem of determining the 
format of a file with an unknown extension?

On 10/13/2011 2:24 AM, edgar.sol...@web.de wrote:
> On 13.10.2011 01:02, Martin Davis wrote:
>> One reason for having the double choice of both format and file name is
>> that there are formats (such as GML) which don't have a standard file
>> extension that can be used to drive the choice of format.
>>
>> Also, in JUMP originally we supported a zipped shapefile concept.  It
>> had the extension .zip, but was read by the Shapefile driver.
>>
>> One thing that could be do would be to use the file extension to drive
>> the initial format setting, but allow it to be overridden for files with
>> non-specific extensions.
>>
> How about a checkbox 'filter by extension', which can be disabled allowing to 
> select any file with any selection in the format dropdown?
>
> ..ede
>
> --
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1410 / Virus Database: 1522/3948 - Release Date: 10/12/11
>
>

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] strings for pan synchronization options are gone

[Martin Davis]

One reason for having the double choice of both format and file name is 
that there are formats (such as GML) which don't have a standard file 
extension that can be used to drive the choice of format.

Also, in JUMP originally we supported a zipped shapefile concept.  It 
had the extension .zip, but was read by the Shapefile driver.

One thing that could be do would be to use the file extension to drive 
the initial format setting, but allow it to be overridden for files with 
non-specific extensions.

I'm also curious how other apps (such as QGIS) handle this?

On 10/12/2011 1:30 PM, edgar.sol...@web.de wrote:
> On 12.10.2011 22:18, Michaël Michaud wrote:
>> Hi,
>>
>> Le 12/10/2011 21:55, edgar.sol...@web.de a écrit :
>>> On 11.10.2011 02:10, Stefan Steiniger wrote:
 The first bug I encountered is MacOSX specific - and we probably forgot
 aboout that "save-ing" bug. I.e. there is no "field" in the Save Dataset
 As dialog to write a name.. one can only chose existing files :(
>>> funny enough it comes up for gml 2.0 ...
>>>
>>> still the whole _double_ drop down select format seems senseless. any 
>>> objections to redesign it to industry standard one dropdown select format?
>> Can't remember a reason for the current design.
>> I agree this is redundant, even if a single combobox will not allow to
>> choose a format and display either files with this format extension
>> and/or files with any extension (not sure it is useful).
>>
> check an application of your choice. this is how a save dialog works usually. 
> select a format, files according selected formats extensions are shown.. 
> choose one or enter your own name.
>
> ede
>
> --
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1410 / Virus Database: 1522/3948 - Release Date: 10/12/11
>
>
>

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Sol Katz Award, was: Union/Dissolve / Sol Katz

[Martin Davis]

Thanks, Stefan and Michael.  It is very nice to have JTS (and I hope 
JUMP too) recognized by the GOSS community like this!

There was some mention of OJ at FOSS4G - mostly I think by people using 
it to view PostGIS data.  But no talks directly on it, at least that I 
noticed.  Be good to get the word out!

There was lots of QGIS activity at FOSS4G.  It seems to me thought that 
OJ may still be a better client for viewing large spatial database data 
(due to the dynamic view capability).  It would be great to really focus 
on making it a great PostGIS client...

Martin


On 10/3/2011 10:55 AM, Stefan Steiniger wrote:
> Oh wow.. Martin - congrats!!!
>
> I haven't read the news up to now - and guess what. Just yesterday I was
> thinking of the award and wondered who got it and that I actually
> proposed you/JTS for lets say 2-3 years. But, now - this year that I did
> not make any suggestion (gave up?), you finally got it.
>
> You deserved it!!!
>
> stefan
>
> On 03/10/2011 12:25 AM, Michaël Michaud wrote:
>> Hi Martin,
>>
>> Sorry, no great secret, just UI improvments.
>> I've already upgraded to UnaryUnion for a while.
>> It was a great algorithmic improvment  !
>>
>> We had two plugins in OpenJUMP (union and dissolve, with some options
>> available in first and missing in second and the other hand).
>> I made a single plugin showing/hiding options depending on the context
>> (selection, layer with/without attribute...).
>>
>> Ah, one thing related to union default  behaviour. We already had mail
>> exchange about it.
>> I think users generally expect that union performs a merge when applied
>> to LineStrings, so I
>> made merging option the default one (can be unselected if needed though).
>>
>> One thing difficult to achieve with union plugin is a significative
>> progress monitor.
>> Any hint for that ?
>>
>> About ten days ago, I've also improved Buffer PlugIn with JTS options
>> which were not
>> available in former plugin (join style and single sided)
>> Now, I'm wondering if I try to include offset curves as an option
>> or if I create another plugin for that. Any idea ?
>>
>> Anyway, here is the url of new NB :
>> http://sourceforge.net/projects/jump-pilot/files/
>> Your remarks are always welcome
>>
>> Finally, as you give me opportunity, I congratulate you for the Sol Katz
>> Award.
>> I mean... for JTS, Sol Kats Award is just what JTS's author has deserved
>> for this
>> great library.
>>
>> Michaël
>>
>>
>>
>>
>> Le 03/10/2011 06:04, Martin Davis a écrit :
>>> Michael,
>>>
>>> What's the secret to the new plugin?   Does it use JTS UnaryUnion, or
>>> something else?
>>>
>>> Martin
>>>
>>> On 10/2/2011 2:33 PM, Michaël Michaud wrote:
>>>> Hi,
>>>>
>>>> Next Nightly Build will include a new version of Union By Attribute
>>>> (dissolve) plugin.
>>>> It is called Union/Dissolve/Merge and has all these capabilities without
>>>> much overhead.
>>>> Dialog box is context sensitive and show only possible options.
>>>>
>>>> If you agree, I'll remove original Union plugin before next release.
>>>>
>>>> Michaël
>>>>
>>>> --
>>>> All of the data generated in your IT infrastructure is seriously valuable.
>>>>
>>>> Why? It contains a definitive record of application performance, security
>>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>>> sense of it. IT sense. And common sense.
>>>> http://p.sf.net/sfu/splunk-d2dcopy2
>>>> ___
>>>> Jump-pilot-devel mailing list
>>>> Jump-pilot-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>
>>>>
>>>> -
>>>> No virus found in this message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 10.0.1410 / Virus Database: 1520/3933 - Release Date: 10/02/11
>>>>
>>>>
>>>>
>>> --
>>> All the data continuously generated in your IT infrastructure contains a
>>> definitive record of customers, application performance, security
>>> threats, fraudulent activity and more. Splunk takes

Re: [JPP-Devel] Union/Dissolve

[Martin Davis]

Michael,

What's the secret to the new plugin?   Does it use JTS UnaryUnion, or 
something else?

Martin

On 10/2/2011 2:33 PM, Michaël Michaud wrote:
> Hi,
>
> Next Nightly Build will include a new version of Union By Attribute
> (dissolve) plugin.
> It is called Union/Dissolve/Merge and has all these capabilities without
> much overhead.
> Dialog box is context sensitive and show only possible options.
>
> If you agree, I'll remove original Union plugin before next release.
>
> Michaël
>
> --
> All of the data generated in your IT infrastructure is seriously valuable.
>
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1410 / Virus Database: 1520/3933 - Release Date: 10/02/11
>
>
>

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Make OpenJUMP to read GML2 with schema saved from WFS 1.0.0

[Martin Davis]

If all those other platforms are able to handle WFS reasonably well, 
that seems to take the wind out of my statement that GML is too hard to 
implement!  Perhaps some of them are implementing a sane subset of GML, 
which would be easier to implement.  I suspect there's an 80-20 
situation here, where most WFS servers are only serving up fairly 
straightforward GML.  (Seems like you still need to parse the schema, 
though, which is hard to see how that could be made simple).

It would be nice to look at the implementations, and follow whichever 
one looks easiest for OJ as well.

But in general I share your frustration about GML.  It originally seemed 
like the answer to an open spatial format standard, but the complexity 
of it is a huge barrier to entry.  (In my wilder moments I daydream that 
It would be nice if the open-source geospatial world got together to 
define a new standard format which would be more practical to implement.!)

Martin

On 8/18/2011 7:21 AM, Rahkonen Jukka wrote:
> Hi Martin,
>
> I just get frustrated every now and then with WFS and GML. It is so simple to 
> get for example the railways from WFS with
> http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=GetFeature&typename=lv:mml_railway
>
> I can see the GML on screen and it looks pretty understandable with all the 
> attributes and geometries.  With a pencil and cross-ruled paper I could even 
> draw the geometries. Then I save the result on disk and believe that 
> everything is OK and I have received a nive set of geospatial data. But 
> actually there are not very many free GIS software being able to open and 
> show the data that was saved on a disk. Schema is missing (nobody told it 
> should have been loaded as well, and the link to schema inside GML does not 
> help you much when on the field off-line), gml cannot be parsed and so on. 
> What have we done to deserve these standards? Not to mention the advanced 
> axis order frustration with WMS 1.3.0, WFS 1.1.0, WCS 1.1 and GML3.
>
> Situation with open source WFS clients is actually rather good now, finally. 
> OpenJUMP does not work any more (or it may with deegree servers but not with 
> others) but Kosmo GIS, gvSIG, QGis and iGeoDesktop are usable as well as uDig 
> and OpenLayers. And for me it is not so big trouble to convert GML from disk 
> into other formats with OGR. However, I would like to teach others to do it 
> in some extremely simple way and not through additional downloads and command 
> line workarounds. Nowadays people tend to give in or escape immediately when 
> they see an open command window.
>
> -Jukka Rahkonen-
>
> Martin Davis wrote:
>
>> Jukka,
>>
>> I may be mis-understanding your post, but the difficulty with reading
>> GML2 from WFS is the same as reading arbitrary GML2: GML
>> schemas can be
>> very complex, and thus it's very difficult to develop a
>> general-purpose
>> GML2 Reader.
>>
>> That is the reason that JUMP implemented the simplified GML2
>> readers for
>> JUMPGML and using a GML template file - to avoid having to
>> parse and map
>> general GML2 schemas.
>>
>> Obviously it is possible to parse general GML2 - GeoTools has a GML2
>> Reader, for instance.  This might be a better direction to go in to
>> bring full GML2 capability to JUMP.
>>
>> Martin
>>
>> On 8/18/2011 1:31 AM, Rahkonen Jukka wrote:
>>> Hi,
>>>
>>> OpenJUMP has a native reader for GML2 but it requires a
>> schema file in the native JUMP format.
>>> On the other hand, WFS 1.0.0 server is sending data as GML.
>> If you want to get some, use the following link, show the
>> source code on a browser and save file on disk
>> http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&r
> equest=GetFeature&typename=lv:mml_railway
>>> The data comes without schema but it can be read from WFS
>> with another request:
>> http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&r
> equest=DescribeFeatureType&typeName=lv:mml_railway
>>> Now I wonder if it could be possible to make OpenJUMP to
>> understand also the WFS schema in addition to the native JUMP
>> schema file so it could parse the GML that comes from WFS? I
>> have tested that SkyJUMP can convert GML into shapefiles with
>> the included iGOR utility but I wonder if GML could be read
>> more directly.
>>> -Jukka Rahkonen-
>>>
>> --
>> 
>>> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
>>> user administration capabilities and model configuration. Take
>>>

Re: [JPP-Devel] Make OpenJUMP to read GML2 with schema saved from WFS 1.0.0

[Martin Davis]

Jukka,

I may be mis-understanding your post, but the difficulty with reading 
GML2 from WFS is the same as reading arbitrary GML2: GML schemas can be 
very complex, and thus it's very difficult to develop a general-purpose 
GML2 Reader.

That is the reason that JUMP implemented the simplified GML2 readers for 
JUMPGML and using a GML template file - to avoid having to parse and map 
general GML2 schemas.

Obviously it is possible to parse general GML2 - GeoTools has a GML2 
Reader, for instance.  This might be a better direction to go in to 
bring full GML2 capability to JUMP.

Martin

On 8/18/2011 1:31 AM, Rahkonen Jukka wrote:
> Hi,
>
> OpenJUMP has a native reader for GML2 but it requires a schema file in the 
> native JUMP format.
> On the other hand, WFS 1.0.0 server is sending data as GML. If you want to 
> get some, use the following link, show the source code on a browser and save 
> file on disk
> http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=GetFeature&typename=lv:mml_railway
>
> The data comes without schema but it can be read from WFS with another 
> request:
> http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=DescribeFeatureType&typeName=lv:mml_railway
>
> Now I wonder if it could be possible to make OpenJUMP to understand also the 
> WFS schema in addition to the native JUMP schema file so it could parse the 
> GML that comes from WFS? I have tested that SkyJUMP can convert GML into 
> shapefiles with the included iGOR utility but I wonder if GML could be read 
> more directly.
>
> -Jukka Rahkonen-
> --
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1392 / Virus Database: 1520/3840 - Release Date: 08/17/11
>
>

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] ESRI file geodatabases

[Martin Davis]

Translation has various problems, such as:
- a cumbersome step before being able to access data
- limitations of the shapefile format (which I presume you would have to 
target for output): e.g. 2 GB limit, dumb column names, limited types, etc

- more storage requirements

Don't get me wrong - I'm not saying that Read-Write to FGDB is not 
needed.  I'm just saying that having Read capability would still provide 
value.


M

On 8/9/2011 7:27 AM, Larry Becker wrote:

Hi Martin,

Disagreed.  ...


Another way to think of this - what better way to to suck the life
out of a proprietary format than to make a one-way gateway into an
open solution?  (This is a tried-and-true ploy of proprietary
platforms...)


I see your point, but if I needed a one way translator, I would just 
use OGR2OGR,  preferably with the iGOR 
interface (after I update it to support FGDB).


I'm also in the position of needing to do advanced editing on data 
that is maintained in ESRI format.  So far it is just shapefiles, but 
the popularity of file geodatabases is increasing.  I can't give the 
customer data back in a different format, especially one that can't 
handle the data size or field names.  I need to be able to edit /along 
side of /the ESRI solution, especially in an ArcGIS Engine runtime 
environment that doesn't have all of the regular tools.


regards,

Larry

On Mon, Aug 8, 2011 at 8:08 PM, Martin Davis <mailto:mtncl...@telus.net>> wrote:




On 8/8/2011 10:33 AM, Larry Becker wrote:

It looks like there could be cooperation between the two groups
on the development of the Java interface at least.

Cooperation with GeoTools seems like a reasonable way to go.



The ogr support approach would not seem to provide any advantage
beyond translating FGDB to shapefiles as SkyJUMP uses that
library for mdb translation now.  There may be Java bindings for
the low level API in OGR that I'm not aware of, but this would be
a level removed from the actual API we want to use.

Agreed.  It's bad enough having to include the C libs needed for
access to non-Java APIs, but including a bunch of OGR libs as well
just compounds the problem.

Also, from a development point-of-view if there are issues that
makes two places which need to be looked at and updated - and if
the problem is in OGR then OJ is hostage to OGR's schedule.



The only way this would be any use in JUMP (IMHO) is if we could
open and edit FGDBs like ArcMap does.  We discussed the idea of
supporting the Access personal geodatabase years ago, but
abandoned the idea because it was too risky because it was
proprietary and had no published API.


Disagreed.  Providing Read-Only access to FGDB is still very
useful, since it provides a gateway into OJ for ESRI users.  And
there is lots of functionality which is difficult to accomplish in
ESRI tools which is easy in OJ (and other Java solutions like
JEQL). I'm now in the unenviable position of working with ESRI
tools on a daily basis, and by the biggest stumbling block to
trying to introduce OJ into my environment is the inability to
read the (sometimes huge) FGDBs that we use.

Another way to think of this - what better way to to suck the life
out of a proprietary format than to make a one-way gateway into an
open solution?  (This is a tried-and-true ploy of proprietary
platforms...)

I'm not even sure that the ESRI FGDB API supports writing.. or at
least, not without a lot of caveats.



As far as the ESRI license, it would put us in the same position
as having the end user download the MRSID executable.  Not good,
but doable.

On the minus side, by supporting the proprietary FGDB format, we
might be using effort that could be better applied to open source
solutions.

See comment above about providing a gateway...


What are the viable open source alternatives?  Spatial Lite seems
to have a C API as well.

SpatialLite support would be useful too, but I don't think it's
going to replace FGDB in the wider world anytime soon (unfortunately).


just a few thoughts,

Larry




On Mon, Aug 8, 2011 at 10:22 AM, mailto:edgar.sol...@web.de>> wrote:

Obviously there is interest in geotools to add a gt2
datastore for it. Also cite:

>Justin Deoliveira: Just a note that fgdb support was
recently added to ogr as a format... so using the existing
ogr datastore (and its java bindings for ogr) could be an
easier route to go. However it requires ogr >= 1.9.0.

In any way we should (re)implement a geotools reader/writer
extension or pimp my old GT2 reader/writer to work with the
latest oj.

ede


On 08.08.2011 17:07, Sunburned Surveyor wrote:
> It 

Re: [JPP-Devel] ESRI file geodatabases

[Martin Davis]

On 8/8/2011 10:33 AM, Larry Becker wrote:
It looks like there could be cooperation between the two groups on the 
development of the Java interface at least.

Cooperation with GeoTools seems like a reasonable way to go.


The ogr support approach would not seem to provide any advantage 
beyond translating FGDB to shapefiles as SkyJUMP uses that library for 
mdb translation now.  There may be Java bindings for the low level API 
in OGR that I'm not aware of, but this would be a level removed from 
the actual API we want to use.
Agreed.  It's bad enough having to include the C libs needed for access 
to non-Java APIs, but including a bunch of OGR libs as well just 
compounds the problem.


Also, from a development point-of-view if there are issues that makes 
two places which need to be looked at and updated - and if the problem 
is in OGR then OJ is hostage to OGR's schedule.


The only way this would be any use in JUMP (IMHO) is if we could open 
and edit FGDBs like ArcMap does.  We discussed the idea of supporting 
the Access personal geodatabase years ago, but abandoned the idea 
because it was too risky because it was proprietary and had no 
published API.


Disagreed.  Providing Read-Only access to FGDB is still very useful, 
since it provides a gateway into OJ for ESRI users.  And there is lots 
of functionality which is difficult to accomplish in ESRI tools which is 
easy in OJ (and other Java solutions like JEQL). I'm now in the 
unenviable position of working with ESRI tools on a daily basis, and by 
the biggest stumbling block to trying to introduce OJ into my 
environment is the inability to read the (sometimes huge) FGDBs that we use.


Another way to think of this - what better way to to suck the life out 
of a proprietary format than to make a one-way gateway into an open 
solution?  (This is a tried-and-true ploy of proprietary platforms...)


I'm not even sure that the ESRI FGDB API supports writing.. or at least, 
not without a lot of caveats.


As far as the ESRI license, it would put us in the same position as 
having the end user download the MRSID executable.  Not good, but doable.


On the minus side, by supporting the proprietary FGDB format, we might 
be using effort that could be better applied to open source solutions.

See comment above about providing a gateway...


What are the viable open source alternatives?  Spatial Lite seems to 
have a C API as well.
SpatialLite support would be useful too, but I don't think it's going to 
replace FGDB in the wider world anytime soon (unfortunately).


just a few thoughts,

Larry




On Mon, Aug 8, 2011 at 10:22 AM, <mailto:edgar.sol...@web.de>> wrote:


Obviously there is interest in geotools to add a gt2 datastore for
it. Also cite:

>Justin Deoliveira: Just a note that fgdb support was recently
added to ogr as a format... so using the existing ogr datastore
(and its java bindings for ogr) could be an easier route to go.
However it requires ogr >= 1.9.0.

In any way we should (re)implement a geotools reader/writer
extension or pimp my old GT2 reader/writer to work with the latest oj.

ede


On 08.08.2011 17:07, Sunburned Surveyor wrote:
> It looks like there is some interest and opportunity for
collaboration
> with the GeoTools team on FGDB support. You can see the thread I
> started on their development mailing list here:
>
>

http://osgeo-org.1803224.n2.nabble.com/FGDB-Support-in-GeoTools-td6662165.html
>
> I'm already way over committed, so I can't take the lead on this
> effort, but I hope we can work together with the GeoTools people if
> there is a desire and resources for work on a FGDB library.
>
> Landon
>
> On Sun, Aug 7, 2011 at 10:44 AM, Sunburned Surveyor
> mailto:sunburned.surve...@gmail.com>> wrote:
>> If we did decide to explore FGDB support for OpenJUMP, I'd
recommend
>> we collaborate with GeoTools on the lower-level code. I can
post there
>> to see if there is anything going on in this area and will get
back to
>> the list.
>>
>> Landon
>>
    >> On Thu, Aug 4, 2011 at 2:25 AM, mailto:edgar.sol...@web.de>> wrote:
>>> Thanks for the overview on this.. ede
>>>
>>> On 04.08.2011 01:28, Martin Davis wrote:
>>>> Yes, they are definitely positioning FGDBs as the replacement
for shapefiles - at least in their world.  FGDB has a lot of
advantages for them - no limit on file size, able to contain all
of the weird and wonderful ESRI data structures, and
platform-independent.  Oh, and no 11-char limit on field names!!!
>>>>
>>>> 
>>>> Personally I can't see it replacing the role that Shapefiles
   

Re: [JPP-Devel] ESRI file geodatabases

[Martin Davis]

Yes, they are definitely positioning FGDBs as the replacement for 
shapefiles - at least in their world.  FGDB has a lot of advantages for 
them - no limit on file size, able to contain all of the weird and 
wonderful ESRI data structures, and platform-independent.  Oh, and no 
11-char limit on field names!!!



Personally I can't see it replacing the role that Shapefiles play in the 
wider geospatial world - that is, a (fairly( open, easily-accessible, 
documented spatial data format.  The FGDB format is closed and 
proprietary - only the API is somewhat open.  And it's written in C, 
which limits its use in some situations.  Also, the FGDB format is very 
complex, and completely tailored to support ESRI's needs, rather than a 
more general set of needs.


It would be GREAT to have a truly open geospatial format, which was 
essentially a shapefile for the 21st century.  GML is NOT that 
format...  so the field lies open



It would be great to have a solution for accessing FGDBs from Java 
(OpenJUMP of course, but I'd also like to be able to read them from 
JEQL).  If OJ could read them that should make it quite appealing for 
working with newer ESRI data.


One possiblity is this work on a Java interface to the FGDB API.  If 
this project has taken care of all the JNI nastiness, then it could be 
worth using.


http://sourceforge.net/projects/jfilegdbexplore/ 



I know that the GDAL project is working on adding a driver for the FGDB 
API.  This is in C, of course, so not directly usable by OJ.


Martin

On 8/3/2011 8:27 AM, Larry Becker wrote:
It would seem that ESRI is positioning the "file geodatabase" as the 
heir to the shapefile.  They now have a cross-platform API that 
provides access without ArcObjects.


http://forums.arcgis.com/threads/31841-Welcome-to-the-discussion-forum-for-the-File-Geodatabase-API!

Is this something the JUMP community should look into supporting?

Larry


--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos&  much more. Register early&  save!
http://p.sf.net/sfu/rim-blackberry-1


___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


No virus found in this message.
Checked by AVG - www.avg.com 
Version: 10.0.1390 / Virus Database: 1518/3807 - Release Date: 08/03/11

--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] New realize of OpenJUMP JUFRE 0.3

[Martin Davis]

Giuseppe,

Wow!  That's a great list of changes.  Based on a quick read of the doc, 
it looks like some great ideas in there.

I'm excited to see so much activity on JUMP - the app is really moving 
forward now!

Martin

On 6/29/2011 4:05 AM, Giuseppe Aruta wrote:
> Hi all
> this is a new version of OpenJUMP Jufre version 0.3.
> The software is based on OpenJUMP 1.4 with more improvements.
>
> - OpenJUMP Jufre 0.3 can be downloaded here:
> http://sourceforge.net/projects/opensit/files/Openjump/Jufre/jufre-1.3.zip/download
>
> - This is the source code of the core software:
> http://sourceforge.net/projects/opensit/files/Openjump/Jufre/jufre-1.3-src.zip/download
>
> - I tried to catalog all the enhancements and changes I did on the core 
> software and I did a list here. Only basicStyle.class modification (for 
> Featurecolorchooser plugIn) is missing. This text explain all the 
> modifications:
> http://sourceforge.net/projects/opensit/files/Openjump/Jufre/read_first.pdf/download.
> Between them:
> - new organization of Editing Toolbox and Attribute schema
> - new plugIn
> - New organization of Schema panel
>
> I will be glad of users/developers impression. I will be "out of web" for a 
> week, so keep questions warm untill 12th of July.
>
> OpenJUMP Jufre is developed to test new enhancements and tools that oner day 
> (I will be glad) will be added to standard OpenJUMP.
> This software is not developed for business or other job activity as it might 
> have some bugs (not yer discovered)
>
> Giuseppe Aruta
>
> --
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1388 / Virus Database: 1516/3732 - Release Date: 06/28/11
>
>

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] R: OpenJUMP 1.4.1rc1

[Martin Davis]

It sounds fine to me to modify or select anything you feel is worth 
including in the JCS plugin, to harmonize with the current OJ menu 
structure.

Martin

On 6/26/2011 3:16 AM, Giuseppe Aruta wrote:
>
>   >  JCS
> I agree to add that QA tool instead of all JCS.  I will ask Martin if we can 
> modify JCS plugIn to armonize with Openjump. As far as I can see in "Jump 
> tribe" there are actually only 4 brenches, excuding Jump itself: OJ, SkyJUMP, 
> AdbToolbox, EcosJUMP  which share the same tools organization on QA.
> I will test on my OJ Jufre experimental version.
>
>
>> Sextante
> I am going to send my modification to Victor and see what's his opinion for 
> Sextante 0.7.
>
>
> Peppe
>
> --
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1388 / Virus Database: 1513/3725 - Release Date: 06/25/11
>
>

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] OpenJUMP 1.4.1 release

[Martin Davis]

Michael,

I can go one step further and create the final build of JTS 1.12.  That 
way you can release with the final version.

Let me know if you want to do this.

Martin

On 6/25/2011 5:06 PM, Martin Davis wrote:
> Sure, that sounds fine.
>
> I'm really hoping to get JTS 1.12 out very soon, and I'm freezing the
> features now, so the RC1 release should be pretty much identical to the
> final one.
>
> Martin
>
> On 6/25/2011 1:50 PM, Michaël Michaud wrote:
>> Hi Martin,
>>
>> I'd like to release OpenJUMP within few days.
>>
>> To be able to use JTS 1.12 new features in my beanshell scripts, I
>> already use the last svn version of JTS.
>> As I know you want to release 1.12 very soon, my idea is to bundle last
>> svn version of JTS in OJ with the name jts-1.12rc1.jar
>>
>> Any idea ?
>>
>> Michaël
>>
>>
>>
>> --
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense..
>> http://p.sf.net/sfu/splunk-d2d-c1
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>>
>> -
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 10.0.1388 / Virus Database: 1513/3725 - Release Date: 06/25/11
>>
>>
>>
> --
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense..
> http://p.sf.net/sfu/splunk-d2d-c1
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1388 / Virus Database: 1513/3725 - Release Date: 06/25/11
>
>
>

--
All the data continuously generated in your IT infrastructure contains a 
definitive record of customers, application performance, security 
threats, fraudulent activity and more. Splunk takes this data and makes 
sense of it. Business sense. IT sense. Common sense.. 
http://p.sf.net/sfu/splunk-d2d-c1
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] OpenJUMP 1.4.1 release

[Martin Davis]

Sure, that sounds fine.

I'm really hoping to get JTS 1.12 out very soon, and I'm freezing the 
features now, so the RC1 release should be pretty much identical to the 
final one.

Martin

On 6/25/2011 1:50 PM, Michaël Michaud wrote:
> Hi Martin,
>
> I'd like to release OpenJUMP within few days.
>
> To be able to use JTS 1.12 new features in my beanshell scripts, I
> already use the last svn version of JTS.
> As I know you want to release 1.12 very soon, my idea is to bundle last
> svn version of JTS in OJ with the name jts-1.12rc1.jar
>
> Any idea ?
>
> Michaël
>
>
>
> --
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense..
> http://p.sf.net/sfu/splunk-d2d-c1
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1388 / Virus Database: 1513/3725 - Release Date: 06/25/11
>
>
>

--
All the data continuously generated in your IT infrastructure contains a 
definitive record of customers, application performance, security 
threats, fraudulent activity and more. Splunk takes this data and makes 
sense of it. Business sense. IT sense. Common sense.. 
http://p.sf.net/sfu/splunk-d2d-c1
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Btter Display/Snapping grid?

[Martin Davis]

There's two parts to this concept - snapping to a dynamic grid, and 
displaying a dynamic grid to show several magnitiudes of grid levels at 
once.

For the Dynamic Grid rendering code, see:

http://jts-topo-suite.svn.sourceforge.net/viewvc/jts-topo-suite/trunk/jts/java/src/com/vividsolutions/jtstest/testbuilder/ui/render/GridRenderer.java?view=log



For the snapping code, see the method

public Point2D toModel(Point2D viewPt) {

and the method snapScale()

in

http://jts-topo-suite.svn.sourceforge.net/viewvc/jts-topo-suite/trunk/jts/java/src/com/vividsolutions/jtstest/testbuilder/Viewport.java?view=log



On 4/28/2011 7:37 AM, Sunburned Surveyor wrote:
> Martin,
>
> Can you give me a pointer to the package(s) in JTS test builder that
> we'd want to look at for code to port to OJ for the grid?
>
> Thanks,
>
> Landon
>
> On Sun, Mar 6, 2011 at 2:20 PM, Martin Davis  wrote:
>> Yes, in the JTS TestBuilder the finest grid is the one snapped to.  It's
>> visually obvious.
>>
>> But... the user doesn't "ask to snap" to a particular grid.  The
>> snapping is always to the grid displayed, which depends on zoom level.
>>
>> I've found this to be more flexible and easier to use than having a
>> single defined snapping grid.  But the two can coexist happily - just
>> display the user-defined grid as well as the variable-size grid.  And
>> allow any or all to be enabled.
>>
>> On 3/6/2011 2:02 PM, Michaël Michaud wrote:
>>>> I think I would snap only to the 1x grid not to deviate coordinate
>>>> inputs when it is not required.
>>> I would also differenciate the 1x grid from others as this is the one
>>> the user asked to snap to.
>>>
>>> Michaël
>>>
>>>
>>> --
>>> What You Don't Know About Data Connectivity CAN Hurt You
>>> This paper provides an overview of data connectivity, details
>>> its effect on application quality, and explores various alternative
>>> solutions. http://p.sf.net/sfu/progress-d2d
>>> ___
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>
>>>
>>> -
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 10.0.1202 / Virus Database: 1435/3485 - Release Date: 03/06/11
>>>
>>>
>>>
>> --
>> What You Don't Know About Data Connectivity CAN Hurt You
>> This paper provides an overview of data connectivity, details
>> its effect on application quality, and explores various alternative
>> solutions. http://p.sf.net/sfu/progress-d2d
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
> --
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1209 / Virus Database: 1500/3601 - Release Date: 04/27/11
>
>
>

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Shape analysis using area-perimeter ratio

[Martin Davis]

We implemented this as part of the JCS Conflation Suite (which was the 
reason JUMP was originally developed!)


There's a whole body of theory around shape recognition - much of which 
is very complicated and hard to implement/use.  The circularity ratio is 
one of the more usable techniques.


Martin

On 4/27/2011 2:00 PM, Larry Becker wrote:
I had a need to classify polygon shapes into general categories such 
as roads and buildings, and I though it might be possible to use a 
"thinness" factor calculated using the area and perimeter.  After 
fooling around with it for a while and not getting the answer, I 
goggled and found the following solution:


lCircularity ratio: the ratio of the area of the shape to the area of 
a circle (the most compact shape) having the same perimeter. 
(area-perimeter ratio)


M = ( 4 * Pi * Area of Polygon) / (Perimeter of Polygon)^2

For a circle, the ratio is one; for a square, it is ? / 4; for an 
infinitely long and narrow shape, it is zero.


I found it at: http://ce.sharif.edu/~alamgir/ 



Further searches indicate that this method of classification may be 
relatively unknown.  Does anyone have knowledge in this area?


regards,

Larry Becker


--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd


___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


No virus found in this message.
Checked by AVG - www.avg.com 
Version: 10.0.1209 / Virus Database: 1500/3600 - Release Date: 04/27/11

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Has anybody done a "Nearest N" tool yet?

[Martin Davis]

On 4/21/2011 9:37 AM, Michaël Michaud wrote:
> I think the approach I described before can give bad results in some 
> corner cases, due to the fact that a part of the searching is based on 
> rectangles (bounding boxes, STRtree nodes) which can give different 
> results from the strict distance between geometries.
>
> Do you think it is the same for your STRtree based algorithm which 
> seems partly based on distances between STRtree nodes ?
No, the approach in the JTS implementation is sound.  It uses the 
distance between STRtree nodes to provide a lower bound on the possible 
distance to the actual data items in (or below) the node.  But 
ultimately the true distance is computed using a distance function 
between the actual items in the tree.  The implementation is pretty 
abstract - it allows the user to provide a distance function for items.  
This could be the normal Euclidean distance between geometries, or it 
could be something more use-specific.
>
>> This will come out in JTS 1.12.0 soon.
> I'm monitoring your website to be sure to include it in OpenJUMP as 
> soon as it is released :-)
>>
>> This code implements 1-NearestNeighbour - k-Nearest would be an 
>> interesting addition.
> I don't have use case for k-Nearest, but I have a somewhat related 
> matching problem
>
> Find features a from A matching features b from B so that :
> a) distance |ab| is alway < max
> b) a can match only one feature from B and reciprocally
> c1) if |ab| < |ab'|, a matches b, even if b' cannot match any other 
> feature
> c2) or matches as many features from A to B (and accept to match a to 
> b' where |ab'| < max, even if  |ab'| > |ab|)
>
> Just gave a quick thought to these problems, but they look like hard 
> to solve without proper algorithms.

I'll have to think about that one!  It sounds somewhat tricky, alright.  
What's the application?


--
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been 
demonstrated beyond question. Learn why your peers are replacing JEE 
containers with lightweight application servers - and what you can gain 
from the move. http://p.sf.net/sfu/vmware-sfemails
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Has anybody done a "Nearest N" tool yet?

[Martin Davis]

Nearest Neighbour seems to be a hot topic all of a sudden.

I recently added NearestNeighbours functionality to the STRtree in JTS.

See here for the source code.

http://jts-topo-suite.svn.sourceforge.net/viewvc/jts-topo-suite/trunk/jts/java/src/com/vividsolutions/jts/index/strtree/STRtree.java?view=log

This will come out in JTS 1.12.0 soon.

This code implements 1-NearestNeighbour - k-Nearest would be an 
interesting addition.


On 4/21/2011 7:25 AM, Michaël Michaud wrote:

Hi,

Interesting problem. Last time I had search nearest features around a 
feature f, I wrote a script doing the following

1) index the dataset to search with STRtree
2) initiate the search with a small distance d
3) search for features in a bounding box equals to bounding box of f + 
distance d in all directions
if features are found, select the nearest of them (or k nearest) 
by a linear search

else set d = 2d and reiterate 3)

Could be implemented as described above in OpenJUMP, but I suspect 
there are better algorithms which could take place in JTS itself


See also
http://en.wikipedia.org/wiki/Nearest_neighbor_search
and the interesting discussion started today on JTS list

Michaël

Le 20/04/2011 16:21, Rahkonen Jukka a écrit :

Hi,
I am just thinking what could be cool to have, I do not have any 
immediate need right now myself. However, I would say that the answer 
in both. I have some ideas about improving the OpenJUMP GPS extension 
for making OJ into a nice vector based moving map program. N nearest 
items from a point would suit that use case. I mean queries like Find 
the closest gas station / restaurant / streetname / maxspeed limit 
from my current GPS location etc.
For more serious work with vector data sets, risk analysis and that 
sort of things the N items nearest to selected item would probably be 
more useful.  And of course the selected item can be a point as 
well.  Your description makes me think that you have a ready tool for 
the latter use case. It would be interesting to test it.

-Jukka Rahkonen-


Larry Becker  wrote:
Hi Jukka,

  Do you want to find the N items nearest to a point or another
item?  I have a tool that looks out a specified distance from a
selected feature and creates a new layer containing lines with
arrowheads between all of the features.  It puts the length in an
attribute so you can use it as a label.  You can then sort by the
length attribute to get the N nearest.

regards,

Larry B.



On Wed, Apr 20, 2011 at 7:44 AM, Rahkonen Jukka
mailto:jukka.rahko...@mmmtike.fi>> wrote:

Hi,
I can find nearest features by having a source layer and
a mask layer and doing a spatial query "is within distance"
by incrementally increasing the distance parameter. It would
be nice to have a tool or script for doing this
automatically.  Even better if the number of features to be
found could be given with another parameter and the actual
distance would be written into the attribute table of the
result layer. Has anybody done this yet?
The selection tool "Select Items by Circle from Selected
Layers" might be usable also if it could be done dynamic so
that user could click at the centre point and drag for giving
the radius before OJ performs the query.
I know I can do what I wand with PostGIS and I guess it is
doable in a similar way with Spatialite but sometimes it
would be handy to search nearest features from shapefiles
simply from OJ map window.
-Jukka Rahkonen-


--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization
is a top
priority.Virtualization can reduce costs, simplify
management, and improve
application availability and disaster protection. Learn more
about boosting
the value of server virtualization.
http://p.sf.net/sfu/vmware-sfdev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel



--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization.http://p.sf.net/sfu/vmware-sfdev2dev


___
Jump-pilot-devel 

Re: [JPP-Devel] Some thoughts for future work on the user interface

[Martin Davis]

Here's my thoughts on a couple of these topics...

* I agree with keeping dependencies as small as possible.  This 
especially applies to "the core".  The core could actually be thought of 
as a few concentric rings of things: the Feature API, the I/O framework 
(and drivers, including DB drivers) the Workbench and plugin framework, 
the GUI, and finally all the various extra plugins.  With reference to 
inode, I'd worry about introducing a dependency for such an important 
part of JUMP (the GUI). What happens if inode is no longer maintained?  
Once that road is followed for any distance it's pretty hard to go back.


* In one of the last versions of the Vivid JUMP we split the codebase 
into 2 jars, core and workbench.  The idea was that the core was 
independently useful for straight Java coding. This is similar to the 
GeoTools/GeoServer split.


* Without knowing more about the impacts on the development process, I'd 
say I'm not really in favour of introducing Groovy into the core JUMP 
codebase.  It seems like it might complicate coding (especially for 
people who don't grok Groovy).  It seems like it might complicate 
upgrading to new versions of Java (how well does Groovy track Java?).  
And does Groovy have limitations in support by the various popular 
IDEs?  It would be nice to have OJ easily used by any Java coding 
environment.


If there's really things for which Groovy is essential, could they go 
into a separate extension?


Martin

On 3/17/2011 2:00 PM, Benjamin Gudehus wrote:

Hi Michaël,

Thanks for your comments and links to docking and plugin 
libraries/frameworks.


 is infonode totally free and opensource ?


InfoNode Docking Windows is under GPL. It looks quite good (as one can 
see in my screenshots) and has a nice API.


One idea I had which may be related to the plugin management is
that OpenJUMP should be able to record plugin actions in macros.


Here's my basic idea.

void execute(Map macroOptions) {
Map optionsForExecute = null;
if (macroOptions) {
optionsForExecute = macroOptions);
} else {
optionsForExecute = Dialog.showAndReturnUserSelection()
// save optionsForExecute with MacroRecorder.
}
// use optionsForExecute to do something.
}

I'm afraid by the addition of a new library for each single
enhancement. [...]


I agree.

I think that keeping a small API and few dependencies is one of
the best chance for OpenJUMP to keep its place in the OpenSource
GIS ecosystem


Here are some greps listing all dependencies between source files and 
jar-files in OpenJUMP.


http://pastebin.com/Npn26PKu

I played around a bit with it and ended up removing 50% of the 
dependencies. The lend me to the idea of spliting OpenJUMP into 
several jars: openjump-core.jar, openjump-scripting.jar (jython, bsh), 
openjump-raster.jar (jai, ...), openjump-gml-svg-sld.jar (batik, 
xml-apis) and openjump-postgis.jar (postgresql).


Just a small idea to minimize dependencies for openjump-core.jar.

- polyglot project java/groovy : I'm not a groovy user (just a
beanshell fan). I think a good enhancement would be to make
scripting in any java compatible sripting language easier. I'm not
in favour of mixing java and groovy in core parts of the project
(or UI). But maybe you have strong arguments, or maybe I
misunderstood what you mean with "create a polyglot project with
Java and  Groovy"


I like the idea of keeping the core in Java and create a new project 
file (thus a separate JAR-file) for the UI. The source code of the UI 
could be in Java and Groovy.


Some words to Groovy: Groovy acts the _same_ as Java (i. e. it 
compiles to .class files), just without unneccessary ceremony. I use 
it throughout my OpenJUMP extension (no single line is in Java). You 
even can rename the extension of a .java file into .groovy and it will 
compile fine (i. e. java syntax is actually a subset of groovy syntax).


Groovy can also used for scripting in applications (just like Jython, 
JRuby or BeanShell). But I don't prefer to do that with Groovy.


--Benjamin


--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d


___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


No virus found in this message.
Checked by AVG - www.avg.com 
Version: 10.0.1202 / Virus Database: 1498/3512 - Release Date: 03/17/11

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/interna

Re: [JPP-Devel] Btter Display/Snapping grid?

[Martin Davis]

Yes, in the JTS TestBuilder the finest grid is the one snapped to.  It's 
visually obvious.

But... the user doesn't "ask to snap" to a particular grid.  The 
snapping is always to the grid displayed, which depends on zoom level.

I've found this to be more flexible and easier to use than having a 
single defined snapping grid.  But the two can coexist happily - just 
display the user-defined grid as well as the variable-size grid.  And 
allow any or all to be enabled.

On 3/6/2011 2:02 PM, Michaël Michaud wrote:
>> I think I would snap only to the 1x grid not to deviate coordinate
>> inputs when it is not required.
> I would also differenciate the 1x grid from others as this is the one
> the user asked to snap to.
>
> Michaël
>
>
> --
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1202 / Virus Database: 1435/3485 - Release Date: 03/06/11
>
>
>

--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Btter Display/Snapping grid?

[Martin Davis]

Yes, the coordinates are snapped to the 1x grid.  Since the 5x, 10x, 
100x grids are just multiples of this, they are also snapped to by 
definition.

One thing I forgot to add is that I also constrain the scale factor to 
be a multiple of a power of 10 (i.e. have single digit precision).  This 
provides enough flexibility in zoom level, while limiting the precision 
of the zoom level to a reasonable value.  This is independent of the 
grid and snapping, and would be easy to implement on its own (simply 
round the scale factor when zooming happens).

Sounds good about adding a Feature Request. I will do this myself in the 
future.  Or do I have to be a committer to do this?  It would be great 
if you can add me as a committer - I'm hoping to have some time and 
ideas to contribute.   My SourceForge ID is dr_jts.

Martin



On 3/6/2011 1:57 PM, Michaël Michaud wrote:
> Hi again,
>> I have never been very happy with the display grid in JUMP.  It's too
>> limited, since it only works well at a very small range of scales.
>> Also, it's fussy to set a grid size all the time.
>>
>> In the JTS TestBuilder I've been experimenting with a better grid design
>> which works well at all scales.  It shows a basic grid which is
>> appropriate for the current view scale.  It also shows multiples of 5x,
>> 10x, and 100x at that scale, to allow better orientation.  Snapping to
>> the grid occurs when the cursor is close to a grid point - otherwise the
>> entry point is not snapped.  The cursor snaps to provide visual feedback.
> Do you also snap coordinates to the 5x, 10x and 100x grid or these one
> are just for visualization ?
> I think I would snap only to the 1x grid not to deviate coordinate
> inputs when it is not required.
> (anyway I'll see how JTS TestBuilder works)
>
>> Also, coordinates are always rounded to a precision which is appropriate
>> to the current scale (e.g. to just below the size of 1 pixel, since the
>> user can't resolve to any more than that anyway).  This prevents the
>> occurence of very high-precision coordinates, which are not meaningful
>> during data entry.
> Good idea :-)
>> I think this might be a nice option for JUMP.  You can try out the
>> design in the SVN version of the JTS TestBuilder to see how it works.
>> If it seems worthwhile, some of the code in the TestBuilder can be
>> reused in in JUMP  (There's a lot of fiddly mathematics to get the grid
>> sizing and snapping right).
> I'll check the code, but I'm not sure we'll have time to port it to
> OpenJUMP soon.
> Anyway, I'll also write a Feature Request for this one.
>
> I just checked JPP member list and see you're still not a committer. Am
> I right ?
> If you think you may have opportunity to commit anything to the project,
> you know you just have to give me your sourceforge user account.
>
> Michaël
>
>> Martin
>>
>> --
>> What You Don't Know About Data Connectivity CAN Hurt You
>> This paper provides an overview of data connectivity, details
>> its effect on application quality, and explores various alternative
>> solutions. http://p.sf.net/sfu/progress-d2d
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>>
>
> --
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1202 / Virus Database: 1435/3485 - Release Date: 03/06/11
>
>
>

--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] Btter Display/Snapping grid?

[Martin Davis]

I have never been very happy with the display grid in JUMP.  It's too 
limited, since it only works well at a very small range of scales.  
Also, it's fussy to set a grid size all the time.

In the JTS TestBuilder I've been experimenting with a better grid design 
which works well at all scales.  It shows a basic grid which is 
appropriate for the current view scale.  It also shows multiples of 5x, 
10x, and 100x at that scale, to allow better orientation.  Snapping to 
the grid occurs when the cursor is close to a grid point - otherwise the 
entry point is not snapped.  The cursor snaps to provide visual feedback.

Also, coordinates are always rounded to a precision which is appropriate 
to the current scale (e.g. to just below the size of 1 pixel, since the 
user can't resolve to any more than that anyway).  This prevents the 
occurence of very high-precision coordinates, which are not meaningful 
during data entry.

I think this might be a nice option for JUMP.  You can try out the 
design in the SVN version of the JTS TestBuilder to see how it works.  
If it seems worthwhile, some of the code in the TestBuilder can be 
reused in in JUMP  (There's a lot of fiddly mathematics to get the grid 
sizing and snapping right).

Martin

--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] Kudos for latest version of OJ

[Martin Davis]

Hey, JUMPers, Martin Davis here.  I'm finally getting back on-list after 
a time away... I'm able to use JUMP more now in my current work, which 
is making me very happy (especially since the alternative is to use ArcGIS!)

The latest version of OJ is looking very good.  Thank you for reverting 
to the blue background for the main window - the black background was 
very depressing!

I noticed a minor potential UI improvement.  In the View menu, it would 
be more consistent to change "Show Scale" to  a toggle item called 
"Scale Display", and move it to be next to the existing "Scale Bar" 
item.  Is there a good place to log this kind of comment?

Martin

--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] font for oj logo needed

[Martin Davis]

You might want to leave it as

JUMP unified mapping framework

The original acronym of JUMP was "Java Unified Mapping Framework".  But 
the word Java is a trademark (now of Oracle).  The possible legal issues 
looked scary, so we changed to a recursive acronym "JUMP Unified Mapping 
Framework".

Given Oracle's recent track record, I would advise staying away from 
using the word Java anywhere as a name or title.

M

On 10/27/2010 11:56 AM, edgar.sol...@web.de wrote:
> anybody? .. ede
>
>  Original Message 
> Subject: typo in openjump_logo.eps
> Date: Wed, 27 Oct 2010 13:07:39 +0200
> From: Edgar Soldin
> To: OpenWrt Development List
>
> I found a color shift in the current splash screen and fixed the according 
> png. But the text below now states as in the eps
>
> "JUMP unified mapping framework" instead of "Java unified .."
>
> Do we have the necessary fonts? Do I have to contact Paola Zanetti, the 
> initial designer?
>
> .. thanks ede
>
> --
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps&  games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] System.out in code

[Martin Davis]

 to output trace/debug log
>> statements and above to a log file.  This could be useful for bug
>> reporting.  As a plugin developer, I can specify my own configuration
>> file that ignores all log statements except those in my own java
>> package, writing them to my console.
>>
>> I know OJ currently uses log4j.  If the OJ team wants to fully go the
>> log4j route, then all I'm suggesting for now is that the 330 output
>> statements get cleaned up.
>>
>> But, Landon, I think you made an excellent point earlier ... some of
>> these statements should also be reported to the user
>> (https://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=Displaying_Debug_Messages)
>> in addition to being logged.
>>
>>
>> Cheers,
>> Kevin
>>
>>
>> On 9/7/2010 8:43 AM, Sunburned Surveyor wrote:
>>> I'll have to take a look at log4J again. Did you imagine exposing a
>>> method to access the logging functionality through the plug-in
>>> context, or through some other mechanism?
>>>
>>> The Sunburned Surveyor
>>>
>>> On Tue, Sep 7, 2010 at 8:29 AM, Kevin Neufeld
>>> wrote:
>>>>On 9/7/2010 7:38 AM, Sunburned Surveyor wrote:
>>>>> Stefan,
>>>>>
>>>>> ... I have used Log4j before,
>>>>> and it seemed a little complicated.
>>>> I find the log4j.properties variant complicated as well.  But the
>>>> log4j.xml [1] configuration variant I find fairly straight forward [2].
>>>> I can include/exclude log messages from particular java packages and log
>>>> priorities.
>>>>
>>>>> I wonder if just having the
>>>>> ability to write messages to a simple plain-text log file would
>>>>> suffice.
>>>>>
>>>> Which is one of many output appenders available to log4j :)  I agree,
>>>> this is what I would recommend.  From user's perspective, one can submit
>>>> the log file when posting a bug report.  We can even include a parameter
>>>> in the JUMP launcher that would temporarily set the log priority to
>>>> debug or even verbose to help with bug reports.
>>>>
>>>> My 2 cents,
>>>> -- Kevin
>>>>
>>>>
>>>> [1] http://wiki.apache.org/logging-log4j/Log4jXmlFormat
>>>> [2] http://wiki.apache.org/logging-log4j/Log4jXmlFormat#Example_2
>>>>
>>>> --
>>>> This SF.net Dev2Dev email is sponsored by:
>>>>
>>>> Show off your parallel programming skills.
>>>> Enter the Intel(R) Threading Challenge 2010.
>>>> http://p.sf.net/sfu/intel-thread-sfd
>>>> ___
>>>> Jump-pilot-devel mailing list
>>>> Jump-pilot-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>
>>> --
>>> This SF.net Dev2Dev email is sponsored by:
>>>
>>> Show off your parallel programming skills.
>>> Enter the Intel(R) Threading Challenge 2010.
>>> http://p.sf.net/sfu/intel-thread-sfd
>>> ___
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>> --
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
> --
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Perfomance-tips for large vector-layers?

[Martin Davis]

Nils, you might try looking at JEQL to do this.

http://tsusiatsoftware.net/jeql/main.html

It's based on the same geometry library as OJ (JTS), and is probably a 
little more suited to running batch operations on large datafiles.

Feel free to contact me directly for more info.

Martin

Nils Kuhn wrote:
> Hi,
>
> unfortunatily, I have to work with some very large vector-layers at the 
> moment (more than 800.000 polygons in some shape-files). I have to 
> select features by attribute, write some selections to new layers, union 
> features by attribute, etc. (classical GIS-tasks).
> That's actually no fun!
> Has anybody some performance-tips?
> What's the best data format for working with large vector-layers in OJ? 
> I loaded a polygon-shape to a postGIS-table via shp2pgsql with a spatial 
> index (GIST) but the loaded table doesn's show a better performance than 
> the shape-file (PostgreSQL-Server is located on a windows-server in a 
> local network).
>
> Regards, Nils
>
> --
> This SF.net email is sponsored by 
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Exposing JUMP as an RMI service?

[Martin Davis]

Interesting, Larry.

What IP protocol does your communication mechanism use?  HTTP, or raw 
IP?  If HTTP, how do you handle it?

I thought of using a simple web service as well, by incorporating one of 
the numerous simple OSS Java HTTP server classes which are around.  (I 
guess you'd need a client too - maybe some of them are symmetrical  
8^).  Then you could use XML or even just Java serialization as the 
language.  Of course, you are basically just reinventing RMI - but maybe 
slightly simpler.  One slight downside of RMI is that you need to run 
the rmiregistry app as well, and you also need to set appropriate JVM 
policies.  This is all fairly easy to do, but it does add complexity and 
more points of failure.

The advantage of using Java serialization for the protocol is that it's 
size-efficient, and eliminates any parsing   Disadvantage is Java only...

I did a small experiment exposing some JTS functions as RMI methods, and 
it worked like a charm.  So RMI is quite viable for doing this.

I'm thinking of adding this to the JTS TestBuilder to allow it to 
function as a "spatial logger".  But this is a low-priority project for 
me right now...

Martin

Larry Becker wrote:
> Hi Martin,
>
> I'm still thinking about your RMI idea.  In SkyJUMP, there is a
> communications module that allows other programs to control it remotely.  It
> doesn't use RMI, but it could be ported to OJ and changed to do so.  It
> includes two bidirectional channels for command and data.  The protocol is
> XML and the module allows arbitrary execution of plugins.  An example is:
>
> 
> 
>   SendDatasetPlugIn
>   
> 
>   
> input-filename
> C:\JUMP\tmp\test.jml
>   
> 
>   
> 
>
> This example causes the current selection to be written to the designated
> file.  Just thought I would keep the ball rolling on this idea.
>
> regards,
> Larry
>
> On Thu, Jun 3, 2010 at 2:39 PM, Martin Davis wrote:
>
>   
>> It occurred to me recently that it might be useful to have a spatial
>> viewer acting as an RMI service for out-of-process or remote clients.  A
>> possible use case would be as a "spatial logger" - a client process
>> could log spatial data generated during the course of execution which
>> would be immediately viewable in the spatial viewer. The neat thing is
>> that this would work during a debug session, so the developer could get
>> a good view of data being processed during the run.
>>
>> For those not familiar with it, RMI makes it almost trivially easy to
>> expose a service endpoint and communicate with it from other Java
>> processes. It would be fairly simple to expose a service that allowed
>> clients to create layers, add features to layers, etc.  Really the
>> service could expose almost anything that can be manipulated in JUMP).
>> It would thus enable a sort of "remote plugin" facility.  I also
>> envision a very simple client API that hid the (fairly trivial) aspects
>> of connecting to an RMI service.
>>
>> This may be a solution in search of a problem - but RMI is so powerful
>> it seems like there must be some applications for it.
>>
>> Has anyone played around with exposing an RMI service from JUMP?
>>
>> --
>> Martin Davis
>> Senior Technical Architect
>> Refractions Research, Inc.
>> (250) 383-3022
>>
>>
>>
>> --
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>> 
>
>   
> 
>
> --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> 
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] Exposing JUMP as an RMI service?

[Martin Davis]

It occurred to me recently that it might be useful to have a spatial 
viewer acting as an RMI service for out-of-process or remote clients.  A 
possible use case would be as a "spatial logger" - a client process 
could log spatial data generated during the course of execution which 
would be immediately viewable in the spatial viewer. The neat thing is 
that this would work during a debug session, so the developer could get 
a good view of data being processed during the run.

For those not familiar with it, RMI makes it almost trivially easy to 
expose a service endpoint and communicate with it from other Java 
processes. It would be fairly simple to expose a service that allowed 
clients to create layers, add features to layers, etc.  Really the 
service could expose almost anything that can be manipulated in JUMP).  
It would thus enable a sort of "remote plugin" facility.  I also 
envision a very simple client API that hid the (fairly trivial) aspects 
of connecting to an RMI service.

This may be a solution in search of a problem - but RMI is so powerful 
it seems like there must be some applications for it.

Has anyone played around with exposing an RMI service from JUMP? 

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] OpenJump

[Martin Davis]

Wow, that's very impressive.  As you say, what is it getting used for?

My JTS experience is that I'm constantly getting surprised at the places 
that it pops up that I have never heard about.  JTS is a bit different 
to OJ, though, in that it's a developer tool rather than an end-user 
tool.  I'd actually expect to hear more from OJ users, since they might 
be a bit less willing to "read the code and figure it out for themselves".

Stefan Steiniger wrote:
> thanks Michael for answering
>
> as a note, we had altogether about 12'000 downloads of OpenJUMP 1.3.1 
> for windows and as zip in the past 6 months. Which makes 2000/month and 
> is more than one year ago where we had about 1200/month.
>
> Now - what are all these people doing with OJ? ;)
>
> our list stats:
> jpp devel: 119 subscribers
> openjump users: 125 subscribers
> (of which 1-2 emails are backups)
>
> --
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
> lucky parental unit.  See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] another jts 1.11 related bug?

[Martin Davis]

Good point, Stefan.   I have to admit, Jon wrote all of that code, so 
I'm probably no more able to decide whether the modification is safe.

Here's an idea - while you're waiting for JTS 1.11.1 or JTS 1.12 with 
the fix, why not encapsulate the validity check in a

GeometryUtil.isValidOrNull(Geometry g)

as I suggested earlier.  Then the logic can easily be added to check for empty 
POINTs and return valid for them.


Stefan Steiniger wrote:
> thanks for fixing and discussing,
>
> now, I would prefer to leave the OJ code as is, and wait for JTS NB (or 
> something alike). Because I don't see an elegant way to avoid isValid 
> checks for EditTransactions.commit(), without telling what type of 
> transaction is done.
>
> I.e. we need to do EditTransactions.commit() right?
> as performed in DeleteSelectedItemsPlugIn.java:99
>
> if not, I would rather change code here, before touching/changing 
> something in EditTransaction that allows the delivery of the transaction 
> type.
>
> mhm.. I am honestly a bit scared to do changes here, because I can not 
> assess what a change in the EditTransaction code can have for side 
> effects - especially with respect to writing something back to real 
> databases. So if a skilled person like Larry or Martin (as the JUMP 
> designer) or Michael or Andreas would propose and do changes - I am 
> totally happy with it.
> Though.. preferring still no code changes at all and rather a change of JTS.
>
> puzzled
> stefan
>
> Martin Davis wrote:
>   
>> But not a *good* reason!  8^)For obvious reasons...  !
>>
>> Larry Becker wrote:
>> 
>>> Hi Martin,
>>>
>>>   Thanks for the fix.  Assuming you meant "why OJ is testing for validity on
>>> a delete", the answer may be because it makes the code simpler.  Not the
>>> best reason, but it is a reason.  :-)
>>>
>>> regards,
>>> Larry
>>>
>>> On Tue, Mar 23, 2010 at 10:52 AM, Martin Davis 
>>> wrote:
>>>
>>>   
>>>   
>>>> Yes, POINT EMPTY is valid.  This is a bug in JTS.  I'll fix this today.
>>>> Thanks, Michael!
>>>>
>>>> One thing that doesn't make sense to me is why JTS is testing for
>>>> validity on a delete?  Surely it's safe to NOT do this, even for Undo?
>>>>
>>>>
>>>> Michaël Michaud wrote:
>>>> 
>>>> 
>>>>> Hi Martin, all,
>>>>>
>>>>> Finally, I think the problem could be a consistency problem in JTS.
>>>>> JTS accepts empty Points, empty LineStrings and empty Polygons created
>>>>>   
>>>>>   
>>>> with
>>>> 
>>>> 
>>>>> factory.createPoint(null) -> POINT EMPTY
>>>>> factory.createLineString(null) -> LINESTRING EMPTY
>>>>> factory.createPolygon(null,null) -> POLYGON EMPTY
>>>>>
>>>>> empty LineString and empty Polygon, which hold an empty
>>>>> CoordinateSequence are seen as valid Geometries
>>>>>
>>>>> on the other hand, empty Point, which also holds an empty
>>>>> CoordinateSequence throws an exception while tested for its validity
>>>>> The reason is Point.isValid() does not test its CoordinateSequence but
>>>>> tests the validity of Point.getCoordinate(), which returns a null in
>>>>> this case.
>>>>>
>>>>> Could you confirm POINT EMPTY should be considered as a valid Geometry ?
>>>>>
>>>>> Michaël
>>>>>
>>>>> Stefan Steiniger a écrit :
>>>>>
>>>>>   
>>>>>   
>>>>>> Hei,
>>>>>>
>>>>>> so by looking on the JUMP code,
>>>>>>
>>>>>> deleting always creates a null geometry:
>>>>>> com.vividsolutions.jump.workbench.ui.GeometryEditor.remove(Geometry g,
>>>>>> Geometry itemToRemove)
>>>>>>
>>>>>> calls
>>>>>>
>>>>>>
>>>>>> 
>>>>>> 
>>>> com.vividsolutions.jump.workbench.ui.GeometryEditor.createNullGeometry(Class
>>>> 
>>>> 
>>>>>> geometryClass)
>>>>>>
>>>>>> so, we could do the change in createNullGeometry() [though I don't
>>>>>> rea

Re: [JPP-Devel] another jts 1.11 related bug?

[Martin Davis]

But not a *good* reason!  8^)For obvious reasons...  !

Larry Becker wrote:
> Hi Martin,
>
>   Thanks for the fix.  Assuming you meant "why OJ is testing for validity on
> a delete", the answer may be because it makes the code simpler.  Not the
> best reason, but it is a reason.  :-)
>
> regards,
> Larry
>
> On Tue, Mar 23, 2010 at 10:52 AM, Martin Davis wrote:
>
>   
>> Yes, POINT EMPTY is valid.  This is a bug in JTS.  I'll fix this today.
>> Thanks, Michael!
>>
>> One thing that doesn't make sense to me is why JTS is testing for
>> validity on a delete?  Surely it's safe to NOT do this, even for Undo?
>>
>>
>> Michaël Michaud wrote:
>> 
>>> Hi Martin, all,
>>>
>>> Finally, I think the problem could be a consistency problem in JTS.
>>> JTS accepts empty Points, empty LineStrings and empty Polygons created
>>>   
>> with
>> 
>>> factory.createPoint(null) -> POINT EMPTY
>>> factory.createLineString(null) -> LINESTRING EMPTY
>>> factory.createPolygon(null,null) -> POLYGON EMPTY
>>>
>>> empty LineString and empty Polygon, which hold an empty
>>> CoordinateSequence are seen as valid Geometries
>>>
>>> on the other hand, empty Point, which also holds an empty
>>> CoordinateSequence throws an exception while tested for its validity
>>> The reason is Point.isValid() does not test its CoordinateSequence but
>>> tests the validity of Point.getCoordinate(), which returns a null in
>>> this case.
>>>
>>> Could you confirm POINT EMPTY should be considered as a valid Geometry ?
>>>
>>> Michaël
>>>
>>> Stefan Steiniger a écrit :
>>>
>>>   
>>>> Hei,
>>>>
>>>> so by looking on the JUMP code,
>>>>
>>>> deleting always creates a null geometry:
>>>> com.vividsolutions.jump.workbench.ui.GeometryEditor.remove(Geometry g,
>>>> Geometry itemToRemove)
>>>>
>>>> calls
>>>>
>>>>
>>>> 
>> com.vividsolutions.jump.workbench.ui.GeometryEditor.createNullGeometry(Class
>> 
>>>> geometryClass)
>>>>
>>>> so, we could do the change in createNullGeometry() [though I don't
>>>> really like the idea here to create an empty GeometryCollection is
>>>> Michael did for the other positions] or in
>>>>
>>>>
>>>> 
>> com.vividsolutions.jump.workbench.ui.EditTransaction.proposedGeometriesValid()
>> 
>>>> by catching null geometries here and not checking them.
>>>>
>>>> or.. of course... both.
>>>>
>>>> any suggestions by you Larry, Michael, Martin?
>>>> Probably the second solution is best?
>>>>
>>>>
>>>> ohh.. @Martin, actually, if that only happens for point geometries
>>>> now... what is with the other geometry.isValid operations... why don't
>>>> they return an error if null geomtries are created?
>>>>
>>>> stefan
>>>>
>>>> Martin Davis wrote:
>>>>
>>>>
>>>> 
>>>>> Ah, yes, right.  This was a bug fix introduced in JTS 1.11, to ensure
>>>>> that Point.isValid checked for invalid (eg NaN) coordinates.
>>>>>
>>>>> In general, the contract for IsValid does not support "null" being
>>>>> passed as in input argument.  OJ should not be trying to determine the
>>>>> validity of a null geometry - it needs to detect this situation and
>>>>>   
>> make
>> 
>>>>> its own decision about whether null is valid or not.
>>>>>
>>>>> So I think the way you'd sum this up is that a bug in JTS 1.10 masked a
>>>>> bug in OJ.
>>>>>
>>>>> Larry, I think your fix should take care of this in OJ.  If it were me
>>>>>   
>> I
>> 
>>>>> would encapsulate that logic in a general-purpose utility method called
>>>>> something like GeometryUtil.isValidOrNull(Geometry g).  That gives a
>>>>> single functionality point for the design decision to allow nulls as
>>>>> valid geometry, in case it needs to be changed in the future.
>>>>>
>>>>> Larry Becker wrote:
>>>>>
>>>

Re: [JPP-Devel] another jts 1.11 related bug?

[Martin Davis]

Yes, POINT EMPTY is valid.  This is a bug in JTS.  I'll fix this today.  
Thanks, Michael!

One thing that doesn't make sense to me is why JTS is testing for 
validity on a delete?  Surely it's safe to NOT do this, even for Undo?


Michaël Michaud wrote:
> Hi Martin, all,
>
> Finally, I think the problem could be a consistency problem in JTS.
> JTS accepts empty Points, empty LineStrings and empty Polygons created with
>
> factory.createPoint(null) -> POINT EMPTY
> factory.createLineString(null) -> LINESTRING EMPTY
> factory.createPolygon(null,null) -> POLYGON EMPTY
>
> empty LineString and empty Polygon, which hold an empty 
> CoordinateSequence are seen as valid Geometries
>
> on the other hand, empty Point, which also holds an empty 
> CoordinateSequence throws an exception while tested for its validity
> The reason is Point.isValid() does not test its CoordinateSequence but 
> tests the validity of Point.getCoordinate(), which returns a null in 
> this case.
>
> Could you confirm POINT EMPTY should be considered as a valid Geometry ?
>
> Michaël
>
> Stefan Steiniger a écrit :
>   
>> Hei,
>>
>> so by looking on the JUMP code,
>>
>> deleting always creates a null geometry:
>> com.vividsolutions.jump.workbench.ui.GeometryEditor.remove(Geometry g, 
>> Geometry itemToRemove)
>>
>> calls
>>
>> com.vividsolutions.jump.workbench.ui.GeometryEditor.createNullGeometry(Class 
>> geometryClass)
>>
>> so, we could do the change in createNullGeometry() [though I don't 
>> really like the idea here to create an empty GeometryCollection is 
>> Michael did for the other positions] or in
>>
>> com.vividsolutions.jump.workbench.ui.EditTransaction.proposedGeometriesValid()
>> by catching null geometries here and not checking them.
>>
>> or.. of course... both.
>>
>> any suggestions by you Larry, Michael, Martin?
>> Probably the second solution is best?
>>
>>
>> ohh.. @Martin, actually, if that only happens for point geometries 
>> now... what is with the other geometry.isValid operations... why don't 
>> they return an error if null geomtries are created?
>>
>> stefan
>>
>> Martin Davis wrote:
>>   
>> 
>>> Ah, yes, right.  This was a bug fix introduced in JTS 1.11, to ensure 
>>> that Point.isValid checked for invalid (eg NaN) coordinates.
>>>
>>> In general, the contract for IsValid does not support "null" being 
>>> passed as in input argument.  OJ should not be trying to determine the 
>>> validity of a null geometry - it needs to detect this situation and make 
>>> its own decision about whether null is valid or not.
>>>
>>> So I think the way you'd sum this up is that a bug in JTS 1.10 masked a 
>>> bug in OJ.
>>>
>>> Larry, I think your fix should take care of this in OJ.  If it were me I 
>>> would encapsulate that logic in a general-purpose utility method called 
>>> something like GeometryUtil.isValidOrNull(Geometry g).  That gives a 
>>> single functionality point for the design decision to allow nulls as 
>>> valid geometry, in case it needs to be changed in the future.
>>>
>>> Larry Becker wrote:
>>> 
>>>   
>>>> I see that prior versions of JTS Point.isValid() didn't call
>>>> IsValidOP.isValid().  It just returned trure.
>>>>
>>>> Stepping though the debugger, isValid is throwing an NPE when it does the
>>>> getCoordinate().
>>>>
>>>>   public boolean isValid() {
>>>>   if (! IsValidOp.isValid(getCoordinate()))
>>>>   return false;
>>>> return true;
>>>>   }
>>>>
>>>> Larry
>>>>
>>>> On Mon, Mar 22, 2010 at 3:58 PM, Larry Becker 
>>>> wrote:
>>>>
>>>>   
>>>>   
>>>> 
>>>>> There are no changes in the SVN history for several months before 24
>>>>> February that seem relevant.  I made a bunch of changes to rendering and
>>>>> such, but nothing related to EditTransactions.
>>>>>
>>>>> I happened to have a copy of OJ dated 22 February and it does not have the
>>>>> delete point problem.  Can't say for sure when it started though.
>>>>>
>>>>> Larry
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Mar 22, 2010 at 3:48 PM, Larry Becker 
>>

Re: [JPP-Devel] another jts 1.11 related bug?

[Martin Davis]

stractPlugIn$1.actionPerformed(AbstractPlugIn.java:130)
>>>> 
>>>>>  at
>>>>>
>>>>>   
>>>> com.vividsolutions.jump.workbench.ui.WorkbenchFrame$24.keyPressed(WorkbenchFrame.java:1142)
>>>> 
>>>>>  at
>>>>>
>>>>>   
>>>> com.vividsolutions.jump.workbench.ui.WorkbenchFrame$9.keyPressed(WorkbenchFrame.java:353)
>>>> 
>>>>>  at
>>>>> java.awt.AWTEventMulticaster.keyPressed(AWTEventMulticaster.java:233)
>>>>>  at java.awt.Component.processKeyEvent(Component.java:6221)
>>>>>  at
>>>>>   
>>>> javax.swing.JComponent.processKeyEvent(JComponent.java:2801)
>>>> 
>>>>>  at java.awt.Component.processEvent(Component.java:6040)
>>>>>  at java.awt.Container.processEvent(Container.java:2041)
>>>>>  at java.awt.Component.dispatchEventImpl(Component.java:4630)
>>>>>  at java.awt.Container.dispatchEventImpl(Container.java:2099)
>>>>>  at java.awt.Component.dispatchEvent(Component.java:4460)
>>>>>  at
>>>>>
>>>>>   
>>>> java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1848)
>>>> 
>>>>>  at
>>>>>
>>>>>   
>>>> java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:704)
>>>> 
>>>>>  at
>>>>>
>>>>>   
>>>> java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:969)
>>>> 
>>>>>  at
>>>>>
>>>>>   
>>>> java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:841)
>>>> 
>>>>>  at
>>>>>
>>>>>   
>>>> java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:668)
>>>> 
>>>>>  at java.awt.Component.dispatchEventImpl(Component.java:4502)
>>>>>  at java.awt.Container.dispatchEventImpl(Container.java:2099)
>>>>>  at java.awt.Window.dispatchEventImpl(Window.java:2475)
>>>>>  at java.awt.Component.dispatchEvent(Component.java:4460)
>>>>>  at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
>>>>>  at
>>>>>
>>>>>   
>>>> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
>>>> 
>>>>>  at
>>>>>
>>>>>   
>>>> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
>>>> 
>>>>>  at
>>>>>
>>>>>   
>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
>>>> 
>>>>>  at
>>>>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
>>>>>  at
>>>>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
>>>>>  at
>>>>>   
>>>> java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
>>>> 
>>>>>   
>>>> --
>>>> 
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> ___
>>>>> Jump-pilot-devel mailing list
>>>>> Jump-pilot-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>>
>>>>>
>>>>>
>>>>>   
>>>>
>>>> --
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> ___
>>>> Jump-pilot-devel mailing list
>>>> Jump-pilot-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>
>>>> 
>>>   
>
>   
> 
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> 
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] another jts 1.11 related bug?

[Martin Davis]

That doesn't sound quite right.  Why is a deleted geometry being checked 
for validity at all?  Is this some consequence of changes made to allow 
null geometries to be handled?  Perhaps the geometry deletion code is 
using null to represent "no feature", rather than "a feature with null 
geometry"?

Larry Becker wrote:
> It should be easy to fix.  Here is the current code:
>
> public boolean proposedGeometriesValid() {
> for (int i = 0; i < proposedGeometries.size(); i++) {
> Geometry proposedGeometry = (Geometry)
> proposedGeometries.get(i);
> if (! proposedGeometry.isValid()) { return false; }
> }
> return true;
> }
>
> We could just add a null Geometry check:
>
> public boolean proposedGeometriesValid() {
> for (int i = 0; i < proposedGeometries.size(); i++) {
> Geometry proposedGeometry = (Geometry)
> proposedGeometries.get(i);
> if (proposedGeometry == null) { return true; }
> if (! proposedGeometry.isValid()) { return false; }
> }
> return true;
> }
>
> But is this the right fix?
>
> Larry
>
> On Mon, Mar 22, 2010 at 12:53 PM, Larry Becker wrote:
>
>   
>> I had no trouble duplicating the problem - just create a point and delete
>> it in a new project.  I don't have a clue as to what is going on though.
>>
>> Larry
>>
>>
>> On Mon, Mar 22, 2010 at 12:40 PM, Martin Davis 
>> wrote:
>>
>> 
>>> Hmm...  JTS 1.11 didn't introduce any changes into IsValidOp, I don't
>>> think.
>>>
>>> Is it possible that JTS is not filtering out null geometries from being
>>> tested by IsValidOp?
>>>
>>> Otherwise, someone will have to debug into the execution and figure out
>>> what exact geometry is causing this problem.
>>>
>>> Stefan Steiniger wrote:
>>>   
>>>> Hei,
>>>>
>>>> I haven't found the time to look into it, but I got this error report
>>>> from Bernd:
>>>>
>>>> the issue is that he can not delete point features in existing projects
>>>> or even just created tets layers. (must have been introduced to the NB
>>>> after Feb 24th)
>>>>
>>>> ava.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.EditTransaction.commit(EditTransaction.java:235)
>>>   
>>>>  at
>>>>
>>>> 
>>> com.vividsolutions.jump.workbench.ui.plugin.DeleteSelectedItemsPlugIn.execute(DeleteSelectedItemsPlugIn.java:99)
>>>   
>>>>  at
>>>>
>>>> 
>>> com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:130)
>>>   
>>>>  at
>>>>
>>>> 
>>> com.vividsolutions.jump.workbench.ui.WorkbenchFrame$24.keyPressed(WorkbenchFrame.java:1142)
>>>   
>>>>  at
>>>>
>>>> 
>>> com.vividsolutions.jump.workbench.ui.WorkbenchFrame$9.keyPressed(WorkbenchFrame.java:353)
>>>   
>>>>  at
>>>> java.awt.AWTEventMulticaster.keyPressed(AWTEventMulticaster.java:233)
>>>>  at java.awt.Component.processKeyEvent(Component.java:6221)
>>>>  at javax.swing.JComponent.processKeyEvent(JComponent.java:2801)
>>>>  at java.awt.Component.processEvent(Component.java:6040)
>>>>  at java.awt.Container.processEvent(Container.java:2041)
>>>>  at java.awt.Component.dispatchEventImpl(Component.java:4630)
>>>>  at java.awt.Container.dispatchEventImpl(Container.java:2099)
>>>>  at java.awt.Component.dispatchEvent(Component.java:4460)
>>>>  at
>>&

Re: [JPP-Devel] another jts 1.11 related bug?

[Martin Davis]

Hmm...  JTS 1.11 didn't introduce any changes into IsValidOp, I don't think.

Is it possible that JTS is not filtering out null geometries from being 
tested by IsValidOp?

Otherwise, someone will have to debug into the execution and figure out 
what exact geometry is causing this problem.

Stefan Steiniger wrote:
> Hei,
>
> I haven't found the time to look into it, but I got this error report 
> from Bernd:
>
> the issue is that he can not delete point features in existing projects 
> or even just created tets layers. (must have been introduced to the NB 
> after Feb 24th)
>
> ava.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.EditTransaction.commit(EditTransaction.java:235)
>  at 
> com.vividsolutions.jump.workbench.ui.plugin.DeleteSelectedItemsPlugIn.execute(DeleteSelectedItemsPlugIn.java:99)
>
>  at 
> com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:130)
>  at 
> com.vividsolutions.jump.workbench.ui.WorkbenchFrame$24.keyPressed(WorkbenchFrame.java:1142)
>  at 
> com.vividsolutions.jump.workbench.ui.WorkbenchFrame$9.keyPressed(WorkbenchFrame.java:353)
>  at 
> java.awt.AWTEventMulticaster.keyPressed(AWTEventMulticaster.java:233)
>  at java.awt.Component.processKeyEvent(Component.java:6221)
>  at javax.swing.JComponent.processKeyEvent(JComponent.java:2801)
>  at java.awt.Component.processEvent(Component.java:6040)
>  at java.awt.Container.processEvent(Container.java:2041)
>  at java.awt.Component.dispatchEventImpl(Component.java:4630)
>  at java.awt.Container.dispatchEventImpl(Container.java:2099)
>  at java.awt.Component.dispatchEvent(Component.java:4460)
>  at 
> java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1848)
>  at 
> java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:704)
>  at 
> java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:969)
>  at 
> java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:841)
>  at 
> java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:668)
>  at java.awt.Component.dispatchEventImpl(Component.java:4502)
>  at java.awt.Container.dispatchEventImpl(Container.java:2099)
>  at java.awt.Window.dispatchEventImpl(Window.java:2475)
>  at java.awt.Component.dispatchEvent(Component.java:4460)
>  at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
>  at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
>  at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
>  at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
>  at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
>  at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
>  at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Error in Difference Operation (JTS/JUMP)

[Martin Davis]

Yes, this is a known design limitation, not a bug.

Sunburned Surveyor wrote:
> Sounds like a user error and not a bug. Can I mark the bug report as closed?
>
> The Sunburned Surveyor
>
> On Mon, Mar 22, 2010 at 9:09 AM, Martin Davis  wrote:
>   
>> That's exactly right, Michael.
>>
>> Also see D7 in the FAQ here:
>> http://tsusiatsoftware.net/jts/jts-faq/jts-faq.html
>>
>>
>> Michaël Michaud wrote:
>> 
>>> Hi,
>>>
>>> I don't understand what is the exact sequence of operations, but I think
>>> that performing difference/union operations using layers which are not
>>> noded together and floating point coordinates will most likely give
>>> micro slivers and micro-holes.
>>> It happens, for example, because intersection points are added in
>>> resulting geometries, but not in source geometries which is let unmodified.
>>> I think that overlay, on the other hand, adds nodes on both layers so
>>> that this kind of problem can be avoided.
>>>
>>> my 2 cents
>>>
>>> Michaël
>>>
>>>
>>> Stefan Steiniger a écrit :
>>>
>>>   
>>>> Hei, just saw that bug report.
>>>> stefan
>>>> 
>>>>
>>>> http://sourceforge.net/tracker/?func=detail&aid=2962200&group_id=118054&atid=679906
>>>>
>>>>
>>>>
>>>>
>>>> I've been able to re-create this error in JUMP using the attached files.
>>>> Using the Source feature, I difference each of the Difference features
>>>> from
>>>> it individually. What I'm left with is an almost correct result. There
>>>> are very small slivers remaining in the differenced area that
>>>> shouldn't be
>>>> there. I confirmed this by unioning the Difference features together and
>>>> comparing the results. The union result of the Difference features has no
>>>> interior rings at or near the sliver areas. (POLYGON
>>>> ((-112.50350053191575 41.07440586524802, -112.50350053191733
>>>> 41.07440586524762, -112.503799 41.074331, -112.50350053191575
>>>> 41.07440586524802))
>>>> 
>>>>
>>>> --
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> 
>>>>
>>>> ___
>>>> Jump-pilot-devel mailing list
>>>> Jump-pilot-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>
>>>>
>>>> 
>>> --
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> ___
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>
>>>
>>>   
>> --
>> Martin Davis
>> Senior Technical Architect
>> Refractions Research, Inc.
>> (250) 383-3022
>>
>>
>> --
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>> 
>
> --
> Download Intel® Pa

Re: [JPP-Devel] Error in Difference Operation (JTS/JUMP)

[Martin Davis]

That's exactly right, Michael.

Also see D7 in the FAQ here: 
http://tsusiatsoftware.net/jts/jts-faq/jts-faq.html


Michaël Michaud wrote:
> Hi,
>
> I don't understand what is the exact sequence of operations, but I think 
> that performing difference/union operations using layers which are not 
> noded together and floating point coordinates will most likely give 
> micro slivers and micro-holes.
> It happens, for example, because intersection points are added in 
> resulting geometries, but not in source geometries which is let unmodified.
> I think that overlay, on the other hand, adds nodes on both layers so 
> that this kind of problem can be avoided.
>
> my 2 cents
>
> Michaël
>
>
> Stefan Steiniger a écrit :
>   
>> Hei, just saw that bug report.
>> stefan
>> 
>>
>> http://sourceforge.net/tracker/?func=detail&aid=2962200&group_id=118054&atid=679906
>>  
>>
>>
>>
>>
>> I've been able to re-create this error in JUMP using the attached files.
>> Using the Source feature, I difference each of the Difference features 
>> from
>> it individually. What I'm left with is an almost correct result. There
>> are very small slivers remaining in the differenced area that 
>> shouldn't be
>> there. I confirmed this by unioning the Difference features together and
>> comparing the results. The union result of the Difference features has no
>> interior rings at or near the sliver areas. (POLYGON
>> ((-112.50350053191575 41.07440586524802, -112.50350053191733
>> 41.07440586524762, -112.503799 41.074331, -112.50350053191575
>> 41.07440586524802))
>> 
>>
>> --
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> 
>>
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>   
>> 
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] delay on rendering

[Martin Davis]

You'd make a good grizzly bear, Larry   8^)

Larry Becker wrote:
> I manufactured a dataset from scratch to try out the problem.
>
> Larry
>
> On Wed, Feb 24, 2010 at 5:01 PM, Larry Becker wrote:
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] delay on rendering

[Martin Davis]

Great! 

I dunno why we (ahem - Jon) didn't notice this way back when we first 
wrote this code.  Always easier not to check for special cases, I 
guess... 8^)

I'm betting this should be faster across the board for linear features.  
The intersection() method is very slow (for use in situations like this).

I should have a look and see what GeoServer does in this case - they 
must have the same problem, and they're usually pretty good at 
optimizing things.  But I bet they just do the same thing that you just 
implemented, Larry.

Larry Becker wrote:
>> So one thoughts is that maybe there's no point in clipping linear
>> features?  I think Swing is pretty good at rendering lines and clipping
>> them by itself.
>>
>> 
>
> Nice work Martin!  I just couldn't bear (8^) the the thought of slow
> linestring rendering, so I added (and committed) a check for linear features
> to the StyleUtil#toShape method and it worked like a charm:
>
> if (!((geometry instanceof LineString) || (geometry instanceof
> MultiLineString)))
> actualGeometry = clipGeometry(geometry, bufferedEnvelope);
>
> The grizzlies are now free to roam at will. :-)  It doesn't seem to have
> slowed down display of other linear data like contours.  It might even be
> faster for those too.  To those of you who want to reproduce the problem, it
> requires a lot of self-crossing linestring segments.
>
> regards,
> Larry
>
> On Wed, Feb 24, 2010 at 11:24 AM, Martin Davis wrote:
>
>   
>> Ok, I've looked at Stefan's killer bear lines.  8^)  (Those grizz sure
>> get around...)
>>
>> I see the very slow performance in OJ.  I also tried this in the JTS
>> Test Builder app, which *doesn't* do an intersection() to clip the
>> geometries to the viewport.  The rendering is lightning fast using this
>> strategy.
>>
>> I did notice that when I ran an intersection with a box, I actually got
>> a JTS topology error!  This is yet another reason why it would be nice
>> to avoid using the full-blown intersection() method to do clipping -
>> it's doing way too much work, and isn't as stable as you'd like for a
>> display use case.
>>
>> So one thoughts is that maybe there's no point in clipping linear
>> features?  I think Swing is pretty good at rendering lines and clipping
>> them by itself.
>>
>> Alternatively, this seems like a perfect case for a "rough clipper" as
>> talked about earlier.
>>
>> BTW, would another optimization be to only clip if the geometry is much
>> larger than the viewport?  If the geometry is only slightly larger, it's
>> probably best to just let Swing do the clipping.  I think I actually
>> prototyped this one time, but I can't remember what the results were like.
>>
>> Larry Becker wrote:
>> 
>>> Hi Stefan,
>>>
>>>   Thanks.  Wow!  Pretty slow rendering indeed.
>>>
>>> Larry
>>>
>>> On Wed, Feb 24, 2010 at 10:35 AM, Stefan Steiniger >> wrote:
>>>
>>>
>>>   
>>>> Hei Larry,
>>>>
>>>> I will send them offline.
>>>>
>>>> stefan
>>>>
>>>> Larry Becker schrieb:
>>>>
>>>> 
>>>>> I'm waiting on Stefan's magic 1000 point polygon.  Mine draws too
>>>>> quickly to benchmark.
>>>>>
>>>>> On Tue, Feb 23, 2010 at 10:08 AM, Sunburned Surveyor
>>>>> mailto:sunburned.surve...@gmail.com>>
>>>>>
>>>>>   
>>>> wrote:
>>>>
>>>> 
>>>>> Larry,
>>>>>
>>>>> Kudos for your work on improving rendering performance in OpenJUMP.
>>>>> Should we test the fix you mention where we "rough clip" large
>>>>> lineStrings that contain the viewport in their bounding box?
>>>>>
>>>>> The Sunburned Surveyor
>>>>>
>>>>> On Mon, Feb 22, 2010 at 3:04 PM, Larry Becker
>>>>> mailto:becker.la...@gmail.com>> wrote:
>>>>>  > If the problem is what we have been assuming, I see where
>>>>> Martin's algorithm
>>>>>  > could be applied:
>>>>>  >
>>>>>  >
>>>>>
>>>>>
>>>>>   
>>>> com.vividsolutions.jump.workbench.ui.renderer.style.StyleUtil#toShape()
>>>&

Re: [JPP-Devel] delay on rendering

[Martin Davis]

Ok, I've looked at Stefan's killer bear lines.  8^)  (Those grizz sure 
get around...)

I see the very slow performance in OJ.  I also tried this in the JTS 
Test Builder app, which *doesn't* do an intersection() to clip the 
geometries to the viewport.  The rendering is lightning fast using this 
strategy.

I did notice that when I ran an intersection with a box, I actually got 
a JTS topology error!  This is yet another reason why it would be nice 
to avoid using the full-blown intersection() method to do clipping - 
it's doing way too much work, and isn't as stable as you'd like for a 
display use case.

So one thoughts is that maybe there's no point in clipping linear 
features?  I think Swing is pretty good at rendering lines and clipping 
them by itself.

Alternatively, this seems like a perfect case for a "rough clipper" as 
talked about earlier.

BTW, would another optimization be to only clip if the geometry is much 
larger than the viewport?  If the geometry is only slightly larger, it's 
probably best to just let Swing do the clipping.  I think I actually 
prototyped this one time, but I can't remember what the results were like.

Larry Becker wrote:
> Hi Stefan,
>
>   Thanks.  Wow!  Pretty slow rendering indeed.
>
> Larry
>
> On Wed, Feb 24, 2010 at 10:35 AM, Stefan Steiniger wrote:
>
>   
>> Hei Larry,
>>
>> I will send them offline.
>>
>> stefan
>>
>> Larry Becker schrieb:
>> 
>>> I'm waiting on Stefan's magic 1000 point polygon.  Mine draws too
>>> quickly to benchmark.
>>>
>>> On Tue, Feb 23, 2010 at 10:08 AM, Sunburned Surveyor
>>> mailto:sunburned.surve...@gmail.com>>
>>>   
>> wrote:
>> 
>>> Larry,
>>>
>>> Kudos for your work on improving rendering performance in OpenJUMP.
>>> Should we test the fix you mention where we "rough clip" large
>>> lineStrings that contain the viewport in their bounding box?
>>>
>>> The Sunburned Surveyor
>>>
>>> On Mon, Feb 22, 2010 at 3:04 PM, Larry Becker
>>> mailto:becker.la...@gmail.com>> wrote:
>>>  > If the problem is what we have been assuming, I see where
>>> Martin's algorithm
>>>  > could be applied:
>>>  >
>>>  >
>>>
>>>   
>> com.vividsolutions.jump.workbench.ui.renderer.style.StyleUtil#toShape()
>> 
>>>  >
>>>  > We could do a conversion of large linestrings whose bounding
>>> boxes contain
>>>  > the viewport,  to "rough clip" MultiLineStrings instead of the
>>> clipGeometry
>>>  > call.  This should enable Java's graphics clipper to do its work
>>>  > efficiently.  The tough part is to not slow down the best case
>>> performance
>>>  > too much.
>>>  >
>>>  > Larry
>>>  >
>>>  >
>>>  > On Mon, Feb 22, 2010 at 4:44 PM, Martin Davis
>>> mailto:mbda...@refractions.net>>
>>>  > wrote:
>>>  >>
>>>  >> Yeah, it seems to me that I haven't seen much speed impact from
>>>  >> rendering fairly large linestrings.  I suppose it's possible
>>> that if the
>>>  >> linestring was really complex the intersection() computation
>>> might be
>>>  >> slow, however.
>>>  >>
>>>  >> In any case, computing a full intersection() is definitely doing
>>> more
>>>  >> work than required for rendering.  So this would be a good thing
>>>   
>> to
>> 
>>>  >> optimize.  It's one of those things which isn't necessarily all
>>>   
>> that
>> 
>>>  >> noticeable, but is quietly burning cycles all the time.
>>>  >>
>>>  >> Larry Becker wrote:
>>>  >> > Better send it to me too.  All the cases I've found  in the
>>> wild render
>>>  >> > very
>>>  >> > quickly.  See the attached for an example.
>>>  >> >
>>>  >> > Larry
>>>  >> >
>>>  >> > On Mon, Feb 22, 2010 at 4:13 PM, Martin Davis
>>>  >> > mailto:mbda...@refractions.net
>>>   
>>>> wrote:
>>>> 
>>> 

Re: [JPP-Devel] delay on rendering

[Martin Davis]

Stefan, I'm curious - can you send them to me too?



Stefan Steiniger wrote:
> Hei Larry,
>
> I will send them offline.
>
> stefan
>
> Larry Becker schrieb:
>   
>> I'm waiting on Stefan's magic 1000 point polygon.  Mine draws too 
>> quickly to benchmark.
>>
>> On Tue, Feb 23, 2010 at 10:08 AM, Sunburned Surveyor 
>> mailto:sunburned.surve...@gmail.com>> wrote:
>>
>> Larry,
>>
>> Kudos for your work on improving rendering performance in OpenJUMP.
>> Should we test the fix you mention where we "rough clip" large
>> lineStrings that contain the viewport in their bounding box?
>>
>> The Sunburned Surveyor
>>
>> On Mon, Feb 22, 2010 at 3:04 PM, Larry Becker
>> mailto:becker.la...@gmail.com>> wrote:
>>  > If the problem is what we have been assuming, I see where
>> Martin's algorithm
>>  > could be applied:
>>  >
>>  >
>> com.vividsolutions.jump.workbench.ui.renderer.style.StyleUtil#toShape()
>>  >
>>  > We could do a conversion of large linestrings whose bounding
>> boxes contain
>>  > the viewport,  to "rough clip" MultiLineStrings instead of the
>> clipGeometry
>>  > call.  This should enable Java's graphics clipper to do its work
>>  > efficiently.  The tough part is to not slow down the best case
>> performance
>>  > too much.
>>  >
>>  > Larry
>>  >
>>  >
>>  > On Mon, Feb 22, 2010 at 4:44 PM, Martin Davis
>> mailto:mbda...@refractions.net>>
>>  > wrote:
>>  >>
>>  >> Yeah, it seems to me that I haven't seen much speed impact from
>>  >> rendering fairly large linestrings.  I suppose it's possible
>> that if the
>>  >> linestring was really complex the intersection() computation
>> might be
>>  >> slow, however.
>>  >>
>>  >> In any case, computing a full intersection() is definitely doing
>> more
>>  >> work than required for rendering.  So this would be a good thing to
>>  >> optimize.  It's one of those things which isn't necessarily all that
>>  >> noticeable, but is quietly burning cycles all the time.
>>  >>
>>  >> Larry Becker wrote:
>>  >> > Better send it to me too.  All the cases I've found  in the
>> wild render
>>  >> > very
>>  >> > quickly.  See the attached for an example.
>>  >> >
>>  >> > Larry
>>  >> >
>>  >> > On Mon, Feb 22, 2010 at 4:13 PM, Martin Davis
>>  >> > mailto:mbda...@refractions.net>>wrote:
>>  >> >
>>  >> >
>>  >> >> Stefan, for future reference can you send the linestring, and the
>>  >> >> viewport which causes the problem?
>>  >> >>
>>  >> >> Stefan Steiniger wrote:
>>  >> >>
>>  >> >>> mhm.. ok, so I would guess the problem is related to the
>> size of the
>>  >> >>> geometries and its drawing?
>>  >> >>> I recently had a problem - drawing a linestring that
>> consisted of more
>>  >> >>> than 1000 points. I couldn't do anything for 20-30 seconds on MS
>>  >> >>> Vista,
>>  >> >>> my XP was a bit faster. However, the problem solved when I
>> connected
>>  >> >>> the
>>  >> >>> 1000 points with linestrings that have only a start and
>> endpoint, i.e.
>>  >> >>> instead of drawing 1 linestring a had to draw now 500, but
>> here the
>>  >> >>> 500
>>  >> >>> lines could be drawn one after each other, and everything is
>> done
>>  >> >>> within
>>  >> >>> 2-3 seconds (instead of 20 secs)
>>  >> >>>
>>  >> >>> (if Larry wants to test, I can send that linestring?)
>>  >> >>>
>>  >> >>> however, I am not sure why working with the 1000 points
>> linestring is
>>  >> >>> so
>>  >> >>> slow (i.e. does paint make so

Re: [JPP-Devel] delay on rendering

[Martin Davis]

Yeah, it seems to me that I haven't seen much speed impact from 
rendering fairly large linestrings.  I suppose it's possible that if the 
linestring was really complex the intersection() computation might be 
slow, however.

In any case, computing a full intersection() is definitely doing more 
work than required for rendering.  So this would be a good thing to 
optimize.  It's one of those things which isn't necessarily all that 
noticeable, but is quietly burning cycles all the time.

Larry Becker wrote:
> Better send it to me too.  All the cases I've found  in the wild render very
> quickly.  See the attached for an example.
>
> Larry
>
> On Mon, Feb 22, 2010 at 4:13 PM, Martin Davis wrote:
>
>   
>> Stefan, for future reference can you send the linestring, and the
>> viewport which causes the problem?
>>
>> Stefan Steiniger wrote:
>> 
>>> mhm.. ok, so I would guess the problem is related to the size of the
>>> geometries and its drawing?
>>> I recently had a problem - drawing a linestring that consisted of more
>>> than 1000 points. I couldn't do anything for 20-30 seconds on MS Vista,
>>> my XP was a bit faster. However, the problem solved when I connected the
>>> 1000 points with linestrings that have only a start and endpoint, i.e.
>>> instead of drawing 1 linestring a had to draw now 500, but here the 500
>>> lines could be drawn one after each other, and everything is done within
>>> 2-3 seconds (instead of 20 secs)
>>>
>>> (if Larry wants to test, I can send that linestring?)
>>>
>>> however, I am not sure why working with the 1000 points linestring is so
>>> slow (i.e. does paint make some tests?)
>>>
>>> stefan
>>>
>>> luca marletta wrote:
>>>
>>>   
>>>> luca marletta
>>>> www.beopen.it
>>>>
>>>>
>>>>
>>>> On Fri, Feb 19, 2010 at 5:42 PM, Larry Becker 
>>>> 
>> wrote:
>> 
>>>>> Hi luca,
>>>>>
>>>>>   When you try to select features, does the status bar quickly show
>>>>>   
>> your
>> 
>>>>> selection count, even though no selection handles appear?
>>>>>
>>>>>   If not, this explains why the right click menu is not appearing.  It
>>>>>   
>> needs
>> 
>>>>> selection information to enable or disable options.
>>>>>
>>>>>   
>>>> Larry, no I had not much problem with showing selection count, is anyway
>>>> 
>> quick.
>> 
>>>> I noticed an important stuff.
>>>>
>>>> May dataset is full of large and aggregated geometry and in this case
>>>> I guess geometry index can not much help.
>>>>
>>>> If I explode all, I reduce the delay a lot.
>>>>
>>>> luca
>>>>
>>>>
>>>> 
>> --
>> 
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______
>>>> Jump-pilot-devel mailing list
>>>> Jump-pilot-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>
>>>> 
>>>   
>> --
>> 
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> ___
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>
>>>
>>>   
>> --
>> Martin Davis
>> Senior Technical Architect
>> Refractions Research, Inc.
>> (250) 383-3022
>>
>>
>>
>> -

Re: [JPP-Devel] delay on rendering

[Martin Davis]

Stefan, for future reference can you send the linestring, and the 
viewport which causes the problem?

Stefan Steiniger wrote:
> mhm.. ok, so I would guess the problem is related to the size of the 
> geometries and its drawing?
> I recently had a problem - drawing a linestring that consisted of more 
> than 1000 points. I couldn't do anything for 20-30 seconds on MS Vista, 
> my XP was a bit faster. However, the problem solved when I connected the 
> 1000 points with linestrings that have only a start and endpoint, i.e. 
> instead of drawing 1 linestring a had to draw now 500, but here the 500 
> lines could be drawn one after each other, and everything is done within 
> 2-3 seconds (instead of 20 secs)
>
> (if Larry wants to test, I can send that linestring?)
>
> however, I am not sure why working with the 1000 points linestring is so 
> slow (i.e. does paint make some tests?)
>
> stefan
>
> luca marletta wrote:
>   
>> luca marletta
>> www.beopen.it
>>
>>
>>
>> On Fri, Feb 19, 2010 at 5:42 PM, Larry Becker  wrote:
>> 
>>> Hi luca,
>>>
>>>   When you try to select features, does the status bar quickly show your
>>> selection count, even though no selection handles appear?
>>>
>>>   If not, this explains why the right click menu is not appearing.  It needs
>>> selection information to enable or disable options.
>>>   
>> Larry, no I had not much problem with showing selection count, is anyway 
>> quick.
>>
>> I noticed an important stuff.
>>
>> May dataset is full of large and aggregated geometry and in this case
>> I guess geometry index can not much help.
>>
>> If I explode all, I reduce the delay a lot.
>>
>> luca
>>
>> --
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>> 
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] delay on rendering

[Martin Davis]

mpiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>> 
>
>
>
>   
> 
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> 
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Find/Substitute geometries

[Martin Davis]

es are the owners, the quantity of water user per
>> year, the year of opening etc..
>> 
>>> b) I have a layer with a single wkt polygon geometry.
>>>   
>> This geometry is, for instance,  a simple circle which
>> represent a well in cartography (but it could be even more
>> complicated multigeometry). This layer represent my "block"
>> 
>>> c) I want to create a new layer where the points are
>>>   
>> substituded by circles, in this case, with the same original
>> attributes (owners, year etc) of the layer a).
>> 
>>>
>>>   
>> Have you tried the Cadplan VertexSymbols plugin. You can
>> define a symbol 
>> as any wkt shape. Great idea in my opinion. Of course, this
>> is not the 
>> same approach.
>> And there are currently several limitations : as far as I
>> can see, there 
>> is no way to scale the symbol when the view is scaled, and
>> this is not 
>> possible to display different symbols for different
>> attribute values.
>> But if this way is not as flexible as what you're
>> suggesting, this is a 
>> much more light solution.
>>
>> I'd like to ask : is the geometry you want to display the
>> actual 
>> geometry of your feature
>> yes ==> why don't you store it as your feature geometry
>> (point, 
>> linestring, polygon or even complex multipolygon) so that
>> it scales with 
>> your map scale
>> no ==> why don't you display it as a symbol (OpenJUMP or
>> Cadplan vertex 
>> symbol) ?
>>
>> Sorry if my questions seem naive : I've more a gis /
>> database culture 
>> than a cad one.
>>
>> Michaël
>>
>> 
>>> I am conscious that this is more a CAD question than a
>>>   
>> GIS one, but it would be sometimes useful in a CAD-GIS
>> exchange projects.
>> 
>>> Right now I use the  "copy"/"past to the point"
>>>   
>> tools with some good resaults exporting a GIS project into
>> an autocad map one, but this procedure requires a long job.
>>
>> 
>>> I wonder if this could be automatized.
>>>
>>> Regards
>>>
>>> Peppe
>>>
>>>
>>> NB -  since I am around another useful cad
>>>   
>> project (Dante's plugins) I wonder if this request (if
>> realize) could be integrated into a more large project, a
>> new CAD toolbar for OJ, where to add all new editing/cad
>> requests.
>> 
>>>
>>>
>>>
>>>   
>> --
>> 
>>> SOLARIS 10 is the OS for Data Centers - provides
>>>   
>> features such as DTrace,
>> 
>>> Predictive Self Healing and Award Winning ZFS. Get
>>>   
>> Solaris 10 NOW
>> 
>>> http://p.sf.net/sfu/solaris-dev2dev
>>> ___
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>
>>>
>>>
>>>   
>> --
>> SOLARIS 10 is the OS for Data Centers - provides features
>> such as DTrace,
>> Predictive Self Healing and Award Winning ZFS. Get Solaris
>> 10 NOW
>> http://p.sf.net/sfu/solaris-dev2dev
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>> 
>
>
>   
>
> --
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
>
> --
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] Demo of using JEQL to apply "blocks" to point locations

[Martin Davis]

Guiseppe,

Attached is a demo JEQL script to perform the "block" replacement. (In 
case the attachment doesn't work, the script is also included below.


If you have any issues getting this to work with Shapefile input, just 
let me know.



--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022



/*==

A demo of replacing point locations with geometric "blocks".

The blocks are named, and are linked to the data table by joining on
the name column.

The blocks and data points are given explicitly here for demo purposes.
They can be read from any data format supported by JEQL (eg Shapefile)

Author: Martin Davis
Date:   2010-Feb-11

===*/

tblock = select * from table (
( "Triangle", POLYGON ((0 0, 20 20, 40 0, 0 0)) )
( "Square",   POLYGON ((0 0, 0 20, 20 20, 20 0, 0 0))  )
) t(name, geometry) ;

tdata = select * from table (

( POINT(100 100), "Triangle"  )
( POINT(200 200), "Square")
( POINT(300 300), "Triangle"  )
( POINT(400 400), "Square")

) t(location, blockType) ;

tout = select Geom.translate(p.geometry, dx, dy) geom, blockType
with {
   cent = Geom.centroid(b.geometry);
   dx = Geom.x(d.location) - Geom.x(cent);
   dy = Geom.y(d.location) - Geom.y(cent);
}
from tblock b
join tdata d on d.blockType == b.name;

// data can be printed for a quick preview  
Print tout;

ShapefileWriter tout file: "output.shp";




/*==

A demo of replacing point locations with geometric "blocks".

The blocks are named, and are linked to the data table by joining on
the name column.

The blocks and data points are given explicitly here for demo purposes.
They can be read from any data format supported by JEQL (eg Shapefile)

Author: Martin Davis
Date:   2010-Feb-11

===*/

tblock = select * from table (
( "Triangle", POLYGON ((0 0, 20 20, 40 0, 0 0)) )
( "Square",   POLYGON ((0 0, 0 20, 20 20, 20 0, 0 0))  )
) t(name, geometry) ;

tdata = select * from table (

( POINT(100 100), "Triangle")
( POINT(200 200), "Square"  )
( POINT(300 300), "Triangle")
( POINT(400 400), "Square"  )

) t(location, blockType) ;

tout = select Geom.translate(p.geometry, dx, dy) geom, blockType
with {
   cent = Geom.centroid(b.geometry);
   dx = Geom.x(d.location) - Geom.x(cent);
   dy = Geom.y(d.location) - Geom.y(cent);
}
from tblock b
join tdata d on d.blockType == b.name;

// data can be printed for a quick preview  
Print tout;

ShapefileWriter tout file: "output.shp";
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Find/Substitute geometries

[Martin Davis]

Guiseppe,

Glad you're interested in JEQL. I'll work on providing a sample script 
to perform the shape substitution that you need. I'll post it here when 
it's done.

Martin

Giuseppe Aruta wrote:
> Hi Martin,
> thanks for your answer, I quickly went to explore yoour JEQL site and it 
> seems very very useful. I downloaded a copy to test it. 
> Regarding your question, it is right: I want to substitute a layer of points 
> with a template geometry (usually a polygon): each point geometry would be 
> substituted with a polygon one and saving the original attributes. 
> I want to test how to do with JEQL . I understood that JEQL works on command 
> line and uses simple(?) text files 
> (http://tsusiatsoftware.net/jeql/user/files/kmlToShape_BCAlbers.jql).
> This would be easier to have some routine processes (substitute all points 
> with the same template, substitute according to an attribute value, etc).
> I ask you if you can give me an example on my previous question (substitute 
> all points (from shapefile A) with a template polygon (from shapefile/WKT B), 
> so I can explore the way.
> thanks in advance
>
> Peppe
>
> --- Mer 10/2/10, Martin Davis  ha scritto:
>
>   
>> Da: Martin Davis 
>> Oggetto: Re: [JPP-Devel] Find/Substitute geometries
>> A: "OpenJump develop and use" 
>> Data: Mercoledì 10 febbraio 2010, 19:52
>> Guiseppe,
>>
>> So what you want is to produce a new layer which contains
>> copies of a 
>> "template" geometry, each one centred at a point of another
>> layer, and 
>> carrying the attributes of those points?
>>
>> You can do this now using JEQL.
>>
>> http://tsusiatsoftware.net/jeql/main.html
>>
>> Martin
>>
>> Giuseppe Aruta wrote:
>> 
>>> Hi all,
>>> this would sound strange, but it would be useful if
>>>   
>> people have to add "blocks" (geometries) on a workbench.
>> 
>>> To explain what I mean I give a sample:
>>>
>>> a) I have a layer of points with their own attributes.
>>>   
>> These points represents, for instance, wells and the
>> attributes are the owners, the quantity of water user per
>> year, the year of opening etc..
>> 
>>> b) I have a layer with a single wkt polygon geometry.
>>>   
>> This geometry is, for instance,  a simple circle which
>> represent a well in cartography (but it could be even more
>> complicated multigeometry). This layer represent my "block"
>> 
>>> c) I want to create a new layer where the points are
>>>   
>> substituded by circles, in this case, with the same original
>> attributes (owners, year etc) of the layer a).
>> 
>>> I am conscious that this is more a CAD question than a
>>>   
>> GIS one, but it would be sometimes useful in a CAD-GIS
>> exchange projects.
>> 
>>> Right now I use the  "copy"/"past to the point"
>>>   
>> tools with some good resaults exporting a GIS project into
>> an autocad map one, but this procedure requires a long job.
>>
>> 
>>> I wonder if this could be automatized.
>>>
>>> Regards
>>>
>>> Peppe
>>>
>>>
>>> NB -  since I am around another useful cad
>>>   
>> project (Dante's plugins) I wonder if this request (if
>> realize) could be integrated into a more large project, a
>> new CAD toolbar for OJ, where to add all new editing/cad
>> requests.
>> 
>>>
>>>
>>>
>>>   
>> --
>> 
>>> SOLARIS 10 is the OS for Data Centers - provides
>>>   
>> features such as DTrace,
>> 
>>> Predictive Self Healing and Award Winning ZFS. Get
>>>   
>> Solaris 10 NOW
>> 
>>> http://p.sf.net/sfu/solaris-dev2dev
>>> ___
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>
>>>
>>>   
>> -- 
>> Martin Davis
>> Senior Technical Architect
>> Refractions Research, Inc.
>> (250) 383-3022
>>
>>
>> --
>> SOLARIS 10 is the OS for Data Centers - provides features
>> such as DTrac

Re: [JPP-Devel] Find/Substitute geometries

[Martin Davis]

Guiseppe,

So what you want is to produce a new layer which contains copies of a 
"template" geometry, each one centred at a point of another layer, and 
carrying the attributes of those points?

You can do this now using JEQL.

http://tsusiatsoftware.net/jeql/main.html

Martin

Giuseppe Aruta wrote:
> Hi all,
> this would sound strange, but it would be useful if people have to add 
> "blocks" (geometries) on a workbench.
> To explain what I mean I give a sample:
>
> a) I have a layer of points with their own attributes. These points 
> represents, for instance, wells and the attributes are the owners, the 
> quantity of water user per year, the year of opening etc..
> b) I have a layer with a single wkt polygon geometry. This geometry is, for 
> instance,  a simple circle which represent a well in cartography (but it 
> could be even more complicated multigeometry). This layer represent my "block"
> c) I want to create a new layer where the points are substituded by circles, 
> in this case, with the same original attributes (owners, year etc) of the 
> layer a).
>
> I am conscious that this is more a CAD question than a GIS one, but it would 
> be sometimes useful in a CAD-GIS exchange projects.
>
> Right now I use the  "copy"/"past to the point" tools with some good resaults 
> exporting a GIS project into an autocad map one, but this procedure requires 
> a long job. 
> I wonder if this could be automatized.
>
> Regards
>
> Peppe
>
>
> NB -  since I am around another useful cad project (Dante's plugins) I wonder 
> if this request (if realize) could be integrated into a more large project, a 
> new CAD toolbar for OJ, where to add all new editing/cad requests.
>
>
>   
>
> --
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> _______
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Using Web Mercator tilesets in JUMP?

[Martin Davis]

Yes, that's it exactly.  There are lots of great tile services out there 
- Google (several kinds), Microsoft, Yahoo, etc.  And of course best of 
all - OpenStreetMap and its derivatives.  And there are lots of custom 
services as well - here at Refractions we've built several.

The tricky part is handling the tile cache naming scheme, and mapping to 
world coordinates.  This could be hard-coded for the more common 
services, but ideally would be able to be overridden by custom code for 
custom services (e.g we have a local one which is in BC-Albers, in ESRI 
tile cache structure). 

OpenLayers has dealt with this issue nicely, so they have lots of code 
examples for the more common cases.

I wonder if it would be possible to provide customization via Beanshell?

The other slightly tricky thing is dealing with the fixed zoom levels of 
tile services.  One option is to force JUMP to adhere to those zoom 
levels when a tile service is being displayed (ideally with the 
provision of a zoom slider as seen on most web maps).  Another option 
that we've implemented in another project is to scale the tile images to 
fit an arbitrary zoom level.  This actually worked surprisingly well for 
us, and was plenty fast enough.

I can contribute some of this code if needed.

Martin

Larry Becker wrote:
> Hi Martin,
>
>   So we're talking about accessing existing image tiles on the web 
> using a URL to georeference them?  We have some code that reads Google 
> street map tiles.  I used to do the same thing with the old 
> Terraserver.   It wouldn't be difficult to throw something together.
>
> regards,
> Larry
>
> On Thu, Feb 4, 2010 at 11:28 AM, Martin Davis  <mailto:mbda...@refractions.net>> wrote:
>
> Has anyone done any work on allowing Web Mercator tilesets to be
> visualized in OJ?  This would be a nice complement to the WMS
> capability.  It also might encourage OSM and OpenCycleMap users to
> make
> use of JUMP.
>
> --
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
>
>
> 
> --
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in
> the business
> Choose flexible plans and management services without long-term
> contracts
> Personal 24x7 support from experience hosting pros just a phone
> call away.
> http://p.sf.net/sfu/theplanet-com
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> <mailto:Jump-pilot-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
>
>
> -- 
> Larry Becker
> Integrated Systems Analysts, Inc.
> 
>
> --
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> ----
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] Using Web Mercator tilesets in JUMP?

[Martin Davis]

Has anyone done any work on allowing Web Mercator tilesets to be 
visualized in OJ?  This would be a nice complement to the WMS 
capability.  It also might encourage OSM and OpenCycleMap users to make 
use of JUMP.

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Jump DB Query Plugin now supports Spatialite

[Martin Davis]

>
> I also prefer pure-java to mixed java/binary, but SQLite apparently
> has a large and growing mindshare.  For instance, the latest version
> of ogr/gdal supports pushing spatial data directly into a SQLite
> database.  I tend to view SQLite like I view other databases, as an
> external resource, and not something you would want to embed in an
> app.   From that point of view, interoperability is good enough.
>
>   
Good point, Larry.  SQLite is exactly analogous to (say) PostGIS, so 
it's implementation technology is not really a concern.

Still nice to have a pure Java driver, though, to avoid the problem of 
platform dependencies.

And I can imagine OJ shipping with an embedded H2 option at some point, 
to seamlessly support huge datasets.

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Jump DB Query Plugin now supports Spatialite

[Martin Davis]

Very interesting.

What did you use as a Spatialite JDBC connection?  Is this pure Java, or 
JNI?

H2 is more appealing to me since it's pure Java - but up til now it 
hasn't had very good spatial support.  The Hatbox project might help 
with that.  It would be nicer to see this capability integrated into the 
original H2 codebase (but then that hasn't seemed to have slowed down 
Spatialite at all, so maybe I worry too much...)

H2 I think also is more flexible than Sqlite - e.g. in-memory databases, 
etc.  But Sqlite is certainly getting deployed in a LOT of large 
projects, so its longevity seems assured.

I guess it would be good to support both!

Michaël Michaud wrote:
> Hi,
>
> Just had a look to Spatialite (not yet Jump DB Query connector, but it 
> will come soon).
> Spatialite is very promising : I like its simplicity. I did not test its 
> capabilities yet, but it can handle much more data than OpenJUMP without 
> the complexity of a database like PostGIS.
>
> I'd like to let you (developper) know that h2 is a pure java database 
> which has most of the SQLite qualities (simplicity, one file storage, 
> in-memory mode...), and that it has now a spatial index called HatBox 
> from Peter Yuill (http://hatbox.sourceforge.net/news.html). AFAIK 
> Geotools has started h2/hatbox integration into Geotools.
> In hatbox, indexes seem to be build in a way which is very similar to 
> spatialite way (i.e trigger updating a Rtree stired in a plain table), 
> and quite different from postgis.
>
> Of course, a complete integration of h2, hatbox and OpenJUMP would be an 
> interesting challenge ;-)
>
> Michaël
>
> Larry Reeder a écrit :
>   
>> Hey all,
>>
>> I wanted to let the group know that the Jump DB Query Plugin now
>> supports Spatialite databases and SQLite databases that follow the FDO
>> RFC 16 specification.  GDAL/OGR and other open source tools use FDO
>> RFC 16 to store spatial data in plain SQLite.  Thanks to Jukka
>> Rahkonen for the idea and QA support, and a big "Thank you" to the
>> OpenJump developers for continuing to support a great open source GIS
>> tool.
>>
>> You can find out more about the plugin at 
>> http://jumpdbqplugin.sourceforge.net/.
>>
>>
>>   -Larry
>>
>> --
>> Throughout its 18-year history, RSA Conference consistently attracts the
>> world's best and brightest in the field, creating opportunities for 
>> Conference
>> attendees to learn about information security's most important issues through
>> interactions with peers, luminaries and emerging and established companies.
>> http://p.sf.net/sfu/rsaconf-dev2dev
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>>
>>   
>> 
>
>
> --
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Proj4j - Martin steps ahead

[Martin Davis]

Kewl!

Sunburned Surveyor wrote:
> Martin wrote: "It's always nice for people to have a UI to use,
> though, so I'd still
> encourage one to be built in OJ."
>
> I'm supposed to be working on that this week. :] If I get a GUI up and
> running for Proj4J I'll think about how I can get it integrated into
> OpenJUMP.
>
> SS
>
> On Wed, Feb 3, 2010 at 9:35 AM, Martin Davis  wrote:
>   
>> Sounds like we're all in agreement.
>>
>> @SS - JEQL now has Proj4J exposed for use.  So this provides a command
>> line tool that pretty much does what you're suggesting.
>>
>> It's always nice for people to have a UI to use, though, so I'd still
>> encourage one to be built in OJ.
>>
>> Stefan Steiniger wrote:
>> 
>>> yep I agree here.
>>> I would say OJ offers options for assigning projections and doing
>>> transformations on a functional basis - i.e. no on the fly stuff? At
>>> least this is the simple way to start with.
>>> Though, we may think then about new measure tools.
>>>
>>> Sunburned Surveyor wrote:
>>>
>>>   
>>>> I found the way UDig handled projections to be a nightmare. Never
>>>> could get it to work right. Now I use FW Tools instead. I'd prefer to
>>>> see projections handled on a per-instance basis. Let the user keep
>>>> track of what projection each layer is in. That is likely something he
>>>> is doing anyways.
>>>>
>>>> This approach will keep the code much simpler.
>>>>
>>>> I think even a stand-alone reprojection tool in Java packaged with
>>>> OpenJUMP might even be the best way to go.
>>>>
>>>> Just my 2 cents.
>>>>
>>>> Landon
>>>>
>>>> On Wed, Feb 3, 2010 at 8:38 AM, Martin Davis  
>>>> wrote:
>>>>
>>>> 
>>>>> Jukka,
>>>>>
>>>>> Do you know what lib spatiallite uses for projections?  Do you have a
>>>>> reference to the doc for it?
>>>>>
>>>>> It seems like it would be nice to have projections built right in to
>>>>> JUMP.  Maybe Proj4J can meet this need, since it's fairly simple and
>>>>> lightweight.
>>>>>
>>>>> People will need to think about how coordinate systems are exposed in
>>>>> JUMP.  Is it just a facility for one-time transformation, with all
>>>>> params supplied by the user?  The next level would keep CRS information
>>>>> with each layer, and automatically reproject imported data. The ultimate
>>>>> (maybe?) level might be to keep data internally in its native CRS and
>>>>> reproject only for display and other purposes.  I think this last might
>>>>> be more complex than its worth, however.  I know uDig spend a lng
>>>>> time getting this right, and it might still be problematic.
>>>>>
>>>>> By the way, something that's not currently in Proj4J is support for
>>>>> mapping to/from the huge variety of CRS specification formats which are
>>>>> out there.  This is a large piece of work, and at this point I don't
>>>>> know when or how it might be accomplished.
>>>>>
>>>>> Rahkonen Jukka wrote:
>>>>>
>>>>>   
>>>>>> Hi,
>>>>>>
>>>>>> Projection support would be nice to have sometimes.  By the way, the two 
>>>>>> new Spatialite plugins give now another alternatives.  Spatialite 
>>>>>> databases which have been created with Spatialite-GUI contains support 
>>>>>> for more than 3000 projections by default.
>>>>>>
>>>>>> -Jukka-
>>>>>>
>>>>>>
>>>>>> Stefan Steiniger wrote:
>>>>>>
>>>>>>
>>>>>> So Guys - guess what:
>>>>>>
>>>>>> Martin revived Proj4j, i.e. Proj4 for Java
>>>>>>
>>>>>> http://lin-ear-th-inking.blogspot.com/2010/01/announcing-proj4j.html
>>>>>>
>>>>>> seems like we can  start thinking about to seriously give OpenJUMP
>>>>>> projection support (for those that don't use PostGIS - like me) ;)
>>>>>>
>>>>>> thank you Martin!
>>>>>>
>>>>>>

Re: [JPP-Devel] Proj4j - Martin steps ahead

[Martin Davis]

Yes, it definitely looks like PROJ4.  I wonder whether they use the same 
SRIDs as PostGIS?  If not, that's yet another set of magic CRS 
number...  sigh.

This is good from the point of view of Proj4J - the more projects that 
use PROJ4, the more reason there is to stay close to that codeline with 
a Java lib.

Rahkonen Jukka wrote:
> Hi,
>
> I would guess it is Proj4. And the table structure looks the same than in 
> PostGIS and transform queries behave in a similar way.
>
> http://www.gaia-gis.it/spatialite/spatialite-tutorial-2.3.1.html#t5
>
> -Jukka-
>
>
> -Alkuperäinen viesti-
> Lähettäjä: Martin Davis [mailto:mbda...@refractions.net]
> Lähetetty: ke 3.2.2010 18:38
> Vastaanottaja: OpenJump develop and use
> Aihe: Re: [JPP-Devel] Proj4j - Martin steps ahead
>  
> Jukka,
>
> Do you know what lib spatiallite uses for projections?  Do you have a 
> reference to the doc for it?
>
> It seems like it would be nice to have projections built right in to 
> JUMP.  Maybe Proj4J can meet this need, since it's fairly simple and 
> lightweight.
>
> People will need to think about how coordinate systems are exposed in 
> JUMP.  Is it just a facility for one-time transformation, with all 
> params supplied by the user?  The next level would keep CRS information 
> with each layer, and automatically reproject imported data. The ultimate 
> (maybe?) level might be to keep data internally in its native CRS and 
> reproject only for display and other purposes.  I think this last might 
> be more complex than its worth, however.  I know uDig spend a lng 
> time getting this right, and it might still be problematic.
>
> By the way, something that's not currently in Proj4J is support for 
> mapping to/from the huge variety of CRS specification formats which are 
> out there.  This is a large piece of work, and at this point I don't 
> know when or how it might be accomplished.
>
> Rahkonen Jukka wrote:
>   
>> Hi,
>>
>> Projection support would be nice to have sometimes.  By the way, the two new 
>> Spatialite plugins give now another alternatives.  Spatialite databases 
>> which have been created with Spatialite-GUI contains support for more than 
>> 3000 projections by default.
>>
>> -Jukka-
>>
>>
>> Stefan Steiniger wrote:
>>
>>  
>> So Guys - guess what:
>>
>> Martin revived Proj4j, i.e. Proj4 for Java
>>
>> http://lin-ear-th-inking.blogspot.com/2010/01/announcing-proj4j.html
>>
>> seems like we can  start thinking about to seriously give OpenJUMP 
>> projection support (for those that don't use PostGIS - like me) ;)
>>
>> thank you Martin!
>>
>> stefan
>>
>> --
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the business
>> Choose flexible plans and management services without long-term contracts
>> Personal 24x7 support from experience hosting pros just a phone call away.
>> http://p.sf.net/sfu/theplanet-com
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>>
>> --
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the business
>> Choose flexible plans and management services without long-term contracts
>> Personal 24x7 support from experience hosting pros just a phone call away.
>> http://p.sf.net/sfu/theplanet-com
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>>   
>> 
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Proj4j - Martin steps ahead

[Martin Davis]

Sounds like we're all in agreement.

@SS - JEQL now has Proj4J exposed for use.  So this provides a command 
line tool that pretty much does what you're suggesting.

It's always nice for people to have a UI to use, though, so I'd still 
encourage one to be built in OJ.

Stefan Steiniger wrote:
> yep I agree here.
> I would say OJ offers options for assigning projections and doing 
> transformations on a functional basis - i.e. no on the fly stuff? At 
> least this is the simple way to start with.
> Though, we may think then about new measure tools.
>
> Sunburned Surveyor wrote:
>   
>> I found the way UDig handled projections to be a nightmare. Never
>> could get it to work right. Now I use FW Tools instead. I'd prefer to
>> see projections handled on a per-instance basis. Let the user keep
>> track of what projection each layer is in. That is likely something he
>> is doing anyways.
>>
>> This approach will keep the code much simpler.
>>
>> I think even a stand-alone reprojection tool in Java packaged with
>> OpenJUMP might even be the best way to go.
>>
>> Just my 2 cents.
>>
>> Landon
>>
>> On Wed, Feb 3, 2010 at 8:38 AM, Martin Davis  wrote:
>> 
>>> Jukka,
>>>
>>> Do you know what lib spatiallite uses for projections?  Do you have a
>>> reference to the doc for it?
>>>
>>> It seems like it would be nice to have projections built right in to
>>> JUMP.  Maybe Proj4J can meet this need, since it's fairly simple and
>>> lightweight.
>>>
>>> People will need to think about how coordinate systems are exposed in
>>> JUMP.  Is it just a facility for one-time transformation, with all
>>> params supplied by the user?  The next level would keep CRS information
>>> with each layer, and automatically reproject imported data. The ultimate
>>> (maybe?) level might be to keep data internally in its native CRS and
>>> reproject only for display and other purposes.  I think this last might
>>> be more complex than its worth, however.  I know uDig spend a lng
>>> time getting this right, and it might still be problematic.
>>>
>>> By the way, something that's not currently in Proj4J is support for
>>> mapping to/from the huge variety of CRS specification formats which are
>>> out there.  This is a large piece of work, and at this point I don't
>>> know when or how it might be accomplished.
>>>
>>> Rahkonen Jukka wrote:
>>>   
>>>> Hi,
>>>>
>>>> Projection support would be nice to have sometimes.  By the way, the two 
>>>> new Spatialite plugins give now another alternatives.  Spatialite 
>>>> databases which have been created with Spatialite-GUI contains support for 
>>>> more than 3000 projections by default.
>>>>
>>>> -Jukka-
>>>>
>>>>
>>>> Stefan Steiniger wrote:
>>>>
>>>>
>>>> So Guys - guess what:
>>>>
>>>> Martin revived Proj4j, i.e. Proj4 for Java
>>>>
>>>> http://lin-ear-th-inking.blogspot.com/2010/01/announcing-proj4j.html
>>>>
>>>> seems like we can  start thinking about to seriously give OpenJUMP
>>>> projection support (for those that don't use PostGIS - like me) ;)
>>>>
>>>> thank you Martin!
>>>>
>>>> stefan
>>>>
>>>> --
>>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>>> Stay online with enterprise data centers and the best network in the 
>>>> business
>>>> Choose flexible plans and management services without long-term contracts
>>>> Personal 24x7 support from experience hosting pros just a phone call away.
>>>> http://p.sf.net/sfu/theplanet-com
>>>> ___
>>>> Jump-pilot-devel mailing list
>>>> Jump-pilot-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>
>>>>
>>>> --
>>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>>> Stay online with enterprise data centers and the best network in the 
>>>> business
>>>> Choose flexible plans and management servi

Re: [JPP-Devel] Proj4j - Martin steps ahead

[Martin Davis]

Jukka,

Do you know what lib spatiallite uses for projections?  Do you have a 
reference to the doc for it?

It seems like it would be nice to have projections built right in to 
JUMP.  Maybe Proj4J can meet this need, since it's fairly simple and 
lightweight.

People will need to think about how coordinate systems are exposed in 
JUMP.  Is it just a facility for one-time transformation, with all 
params supplied by the user?  The next level would keep CRS information 
with each layer, and automatically reproject imported data. The ultimate 
(maybe?) level might be to keep data internally in its native CRS and 
reproject only for display and other purposes.  I think this last might 
be more complex than its worth, however.  I know uDig spend a lng 
time getting this right, and it might still be problematic.

By the way, something that's not currently in Proj4J is support for 
mapping to/from the huge variety of CRS specification formats which are 
out there.  This is a large piece of work, and at this point I don't 
know when or how it might be accomplished.

Rahkonen Jukka wrote:
> Hi,
>
> Projection support would be nice to have sometimes.  By the way, the two new 
> Spatialite plugins give now another alternatives.  Spatialite databases which 
> have been created with Spatialite-GUI contains support for more than 3000 
> projections by default.
>
> -Jukka-
>
>
> Stefan Steiniger wrote:
>
>  
> So Guys - guess what:
>
> Martin revived Proj4j, i.e. Proj4 for Java
>
> http://lin-ear-th-inking.blogspot.com/2010/01/announcing-proj4j.html
>
> seems like we can  start thinking about to seriously give OpenJUMP 
> projection support (for those that don't use PostGIS - like me) ;)
>
> thank you Martin!
>
> stefan
>
> --
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> --
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Null handling in OJ and in PlugIns

[Martin Davis]

I don't think selecting features with null geometry should be a 
problem.  As you say, this can only be done in the Attribute View, not 
spatially - but the behaviour of the selected feature should be pretty 
straightforward.  It's in the selection set, but just isn't displayed.   

Another issue will be plugins - they should all be written to check for 
null geometry if they are using it, and take appropriate action (which 
will depend on the plugin).

One way to find the problem areas is to create some null geometry and 
then work with it in JUMP, watching for exceptions.



Sunburned Surveyor wrote:
> Well, maybe we need to put together a list of places where OpenJUMP
> might choke on a null geometry, and then we can test a fix.
>
> Here is a start:
>
> 1) When the feature is about to be rendered.
> 2) When the user attempts to select the feature on the screen from the
> attribute table.
> 3) When the user attempts to flash the feature on the screen from the
> attribute table.
>
> Can we think of any others?
>
> I'm a little nervous about how we handle the concept of "selecting"
> features with no geometry. We will only be able to do this through the
> attribute table or through attribute queries, and not on the screen.
> Is that going to dork anything up?
>
> I can work on this fix to support null geometries over the next few
> weeks if it is something the group decides to move forward with. I am
> going to copy Stefan on this e-mail so he can comment if he wants to.
>
> SS
>
>
> On Thu, Jan 28, 2010 at 8:43 AM, Martin Davis  wrote:
>   
>> I think in the past I"ve used the convention that null geometry is
>> represented as GEOMETRYCOLLECTION EMPTY.  That way most or all of the
>> JUMP functions should still work, but the user doesn't have to try and
>> distinguish between a real geometry and one which is just a placeholder
>> for null.
>>
>> Ideally JUMP would be able to handle null geometries in the GEOMETRY
>> column as well - this should be fairly easy to add in, since it mostly
>> just means checking and returning before doing anything.
>>
>> Rahkonen Jukka wrote:
>> 
>>> Hi,
>>>
>>> It would be a correct behaviour to get nulls instead of zeros, I hope you 
>>> can fix it. But check what happens if some attribute in a table or in the 
>>> result set of a query contains only NULLs.  The attribute field should 
>>> still appear to OpenJUMP layer schema, and it should be of a correct data 
>>> type.
>>>
>>> More fundamental question is what to do if geometry field is NULL. It is 
>>> not so uncommon situation with databases, and the aim of many GIS projects 
>>> is just to add spatial data for existing objects with already known 
>>> attribute data by locating them on map.
>>>
>>> At present if the result of a PostGIS query contains only NULL geometries 
>>> OpenJUMP throws a Null Pointer Exception. If there are both real geometries 
>>> and NULL geometries in the result se, the lines which are missing geometry 
>>> are skipped.
>>>
>>> A DB Query Plugin by Larry Reeder is using a workaroud that has been very 
>>> usable for me: if geometry is missing the plugin creates a default geometry 
>>> as a little rectangle polygon at the origo. By that way user gets the 
>>> schema and attributes to OpenJUMP even if the geometry is empty. What is 
>>> missing is a clever tool for digitizing the real geometry and inserting it 
>>> in place of the default geometry.
>>>
>>> So what do developers think about what to do with features which do not 
>>> have geometry?  I am remembering that JUMP itself does not necessarily need 
>>> geometry and I am rather sure that I have even seen such things in 
>>> OpenJUMP. I quess I got them to OpenJUMP through opening some shapefile.
>>>
>>> -Jukka Rahkonen-
>>>
>>>
>>>
>>> Michaël Michaud wrote:
>>>
>>>
>>>   
>>>> Hi,
>>>>
>>>> I've got a question for database experts.
>>>> In DatabaseQueryPlugIn, the following JDBC methods are used to get
>>>> numeric attributes from database features
>>>> - ResultSet.getInt()
>>>> - ResultSet.getDouble()
>>>> those methods return  an int and a double, even if the
>>>> database contains
>>>> NULL
>>>> NULL : getInt() --> 0
>>>> NULL : getDouble() --> 0.0
>>>> I think that OpenJUMP should get a null value each time the database
>>>

Re: [JPP-Devel] Null handling in OJ and in PlugIns

[Martin Davis]

I think in the past I"ve used the convention that null geometry is 
represented as GEOMETRYCOLLECTION EMPTY.  That way most or all of the 
JUMP functions should still work, but the user doesn't have to try and 
distinguish between a real geometry and one which is just a placeholder 
for null.

Ideally JUMP would be able to handle null geometries in the GEOMETRY 
column as well - this should be fairly easy to add in, since it mostly 
just means checking and returning before doing anything.

Rahkonen Jukka wrote:
> Hi,
>
> It would be a correct behaviour to get nulls instead of zeros, I hope you can 
> fix it. But check what happens if some attribute in a table or in the result 
> set of a query contains only NULLs.  The attribute field should still appear 
> to OpenJUMP layer schema, and it should be of a correct data type.
>
> More fundamental question is what to do if geometry field is NULL. It is not 
> so uncommon situation with databases, and the aim of many GIS projects is 
> just to add spatial data for existing objects with already known attribute 
> data by locating them on map. 
>
> At present if the result of a PostGIS query contains only NULL geometries 
> OpenJUMP throws a Null Pointer Exception. If there are both real geometries 
> and NULL geometries in the result se, the lines which are missing geometry 
> are skipped.
>
> A DB Query Plugin by Larry Reeder is using a workaroud that has been very 
> usable for me: if geometry is missing the plugin creates a default geometry 
> as a little rectangle polygon at the origo. By that way user gets the schema 
> and attributes to OpenJUMP even if the geometry is empty. What is missing is 
> a clever tool for digitizing the real geometry and inserting it in place of 
> the default geometry.
>
> So what do developers think about what to do with features which do not have 
> geometry?  I am remembering that JUMP itself does not necessarily need 
> geometry and I am rather sure that I have even seen such things in OpenJUMP. 
> I quess I got them to OpenJUMP through opening some shapefile.
>
> -Jukka Rahkonen-
>
>
>
> Michaël Michaud wrote:
>
>   
>> Hi,
>>
>> I've got a question for database experts.
>> In DatabaseQueryPlugIn, the following JDBC methods are used to get 
>> numeric attributes from database features
>> - ResultSet.getInt()
>> - ResultSet.getDouble()
>> those methods return  an int and a double, even if the 
>> database contains 
>> NULL
>> NULL : getInt() --> 0
>> NULL : getDouble() --> 0.0
>> I think that OpenJUMP should get a null value each time the database 
>> contains a NULL value.
>>
>> If this there is no special reason to use those methods, I'll 
>> change the 
>> code to get null instead of 0 in this special cases.
>>
>> Thanks for any suggestion
>>
>> Michaël
>>
>> NB : I noticed another problem with null handling in 
>> SimpleQueryPlugIn. 
>> I fixed it in the svn that way :
>> select features from layer1 where name = (empty combo box) 
>> now returns 
>> empty strings AND nulls (empty strings and null are very similar from 
>> the end-user point of view)
>> I added "is null" as a function to be able to differentiate null from 
>> empty string cases
>> There maybe some corner cases  which are still not perfectly handled 
>> (when there are null in the dataset and the operator is not 
>> "equal" for 
>> example)
>>
>> --
>> 
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network 
>> in the business
>> Choose flexible plans and management services without 
>> long-term contracts
>> Personal 24x7 support from experience hosting pros just a 
>> phone call away.
>> http://p.sf.net/sfu/theplanet-com
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>> 
>
> --
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> ___
> Jump-pilot-devel mail

Re: [JPP-Devel] Possibility to automate openJUMP

[Martin Davis]

Helmut,

Interesting idea...

You are basically asking how to communicate with OpenJUMP via IPC 
(Inter-process communication).  There are a couple of standard ways to 
do this in Java:

1) RMI
2) Web services

You might also look at JMX, which is a user-friendly wrapper for the 
above technologies.

So implementing the basic communication mechanism is fairly 
straightforward.  The real work would be in building the code in OJ to 
connect OJ functions to the IPC interface.  OJ hasn't been designed with 
this in mind, so it's hard to say how difficult this would be.  However, 
OJ is pretty good about following the MVC paradigm, so it might not be 
too much of a stretch to add a new kind of controller (the C part).

I'm curious - what is the application which is actually going to calling 
OJ?  Is there any possibility of hosting this application within OJ 
(which allow you to control OJ more directly).

Another option is that JUMP was originally designed to be 
component-based, with the idea that its UI components and core 
functionality could be easily integrated into other applications.   This 
could be worth looking at - it again would provide a higher degree of 
control and perhaps a simpler overall architecture.

It would be quite interesting to add an IPC capability to OJ - perhaps 
that would be of interest to others as well.

Martin


Helmut Seidel M.A. wrote:
> Hello everybody,
>
> I wonder if it is possible to automate openJUMP from external 
> Applications like Microsofts ActiveX, i.e. call functions like zooming 
> or selecting shapes. I writing a standalone Java-Database-Application 
> and would like to zoom to selected Items (selected in the database) in 
> openJUMP and select them, etc.
>
> If this would be possible, could anybody supply a peace of example-code?
>
> Thanks
> -- 
>
> KnowHow - Helmut Seidel M.A.
>
> Softwareentwicklung - Schulung - Coaching
>
> Gabelsbergerstraße 17 B
>
> 84034 Landshut
>
> Telefon: (08 71) 9 66 52 30
>
> E-Mail: i...@knowhow-la.de
>
> Internet: www.knowhow-la.de
>
> 
>
> --
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> 
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] JTS source code

[Martin Davis]

The JTS source has not yet be moved to this SVN.  I'm hoping to do that 
soon (but maybe not til January)

Martin

Michaël Michaud wrote:
> Larry Becker a écrit :
>   
>> You can download the source to JTS here: 
>> http://jts-topo-suite.svn.sourceforge.net/viewvc/jts-topo-suite/trunk/
>> 
> Can you really see the source from this address,
> I only see a structure with an empty trunk and an empty branches directory.
>
> Not sure if Martin did migrate his code from jump-project cvs to 
> sourceforge.
>
> Michaël
>
>
>
> --
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] 3D develop in OJ

[Martin Davis]

t;>
>> a simple mean of Z weighted on 1/distance.
>>
>> and when you move this vertex it takes the Z of the
>> destination vertex
>> even if this is a behavior in my opinion convenient but
>> someone could
>> have different idea.
>>
>> I think is quite simple for the maintainer of these class and for
>> working in 3D is a simple but great enhancement.
>>
>>
>> By the way: is normal that if run OJ from Eclipse (source from
>> svn)
>> the tools menu is in another place and trunked of a lot of items?
>>
>>
>> thanks a lot
>>
>> luca
>>
>> luca marletta
>> www.beopen.it <http://www.beopen.it>
>>
>> 
>> --
>> Return on Information:
>> Google Enterprise Search pays you back
>> Get the facts.
>> http://p.sf.net/sfu/google-dev2dev
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> <mailto:Jump-pilot-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>>
>>
>>
>> -- 
>> Larry Becker
>> Integrated Systems Analysts, Inc.
>>
>>
>>
>>
>> -- 
>> Larry Becker
>> Integrated Systems Analysts, Inc.
>> 
>>
>> ----------
>> Return on Information:
>> Google Enterprise Search pays you back
>> Get the facts.
>> http://p.sf.net/sfu/google-dev2dev
>>   
>> 
>>
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>   
>> 
>
>
> --
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] JTS mailing list - new location

[Martin Davis]

Stefan,

Yes, the list went down unexpectedly, so I couldn't send out an email 
announcing it!

I have the list of subscribers, so I'm going to try and send one out soon.

Martin

Stefan Steiniger wrote:
> Hei Martin,
>
> thanks for the update.
> I just recognized that I got my last jts email (digest mode) on November 
> 6th... so there was no general email going out to list members? In case 
> that is true, can you send a message to all old members?
>
> stefan
>
> Martin Davis wrote:
>   
>> For anyone interested, the JTS mailing list is now here:
>>
>> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>>
>> Please spread the word!
>>
>> Martin
>>
>> 
>
> --
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] JTS mailing list - new location

[Martin Davis]

For anyone interested, the JTS mailing list is now here:

https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user

Please spread the word!

Martin

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] SkyJUMP generating PDF directly with layers

[Martin Davis]

t;http://www.lowagie.com/iText/>library.
> >>>
> >>> http://www.ashsiii.com/downloads/SkyJUMP.pdf
> >>>
> >>> regards,
> >>> Larry Becker
> >>> Integrated Systems Analysts, Inc.
> >>>
> >>>
> >>>
> >>>
> >>
> 
> --
> >>> Let Crystal Reports handle the reporting - Free Crystal
> Reports 2008
> >> 30-Day
> >>> trial. Simplify your report design, integration and deployment
> - and
> >> focus
> >>> on
> >>> what you do best, core application coding. Discover what's new
> with
> >>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> >>> ___
> >>> Jump-pilot-devel mailing list
> >>> Jump-pilot-devel@lists.sourceforge.net
> <mailto:Jump-pilot-devel@lists.sourceforge.net>
> >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >>>
> >>
> >>
> >> --
> >> Larry Becker
> >> Integrated Systems Analysts, Inc.
> >>
> >>
> >>
> >>
> 
> --
> >> Let Crystal Reports handle the reporting - Free Crystal Reports
> 2008 30-Day
> >> trial. Simplify your report design, integration and deployment
> - and focus
> >> on
> >> what you do best, core application coding. Discover what's new with
> >> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> >> ___
> >> Jump-pilot-devel mailing list
> >> Jump-pilot-devel@lists.sourceforge.net
> <mailto:Jump-pilot-devel@lists.sourceforge.net>
> >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >>
> >
> >
> >
>
> 
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports
> 2008 30-Day
> trial. Simplify your report design, integration and deployment -
> and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> <mailto:Jump-pilot-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> 
> ------
> Let Crystal Reports handle the reporting - Free Crystal Reports
> 2008 30-Day
> trial. Simplify your report design, integration and deployment -
> and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> <mailto:Jump-pilot-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
>
>
> -- 
> Larry Becker
> Integrated Systems Analysts, Inc.
> 
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> 
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] OpenJUMP extension for JEQL?

[Martin Davis]

JUMPers,

For quite a while now I've been working on a query 
engine/system/language for doing processing on spatial datasets.  It's 
called JEQL, and there's some information about it here:  
http://tsusiatsoftware.net/jeql/main.html

For almost as long I've had the goal of creating an OpenJUMP extension 
which would expose the power of JEQL inside OJ.  The idea would be that 
users could write JEQL queries to create new datasets from existing 
ones, or even execute entire JEQL scripts inside JUMP (for instance, to 
do things like read and write file formats, or do coordinate system 
tranformations)

I haven't got very far with creating this extension, so I'm wondering if 
there is an OJ developer who would like to collaborate on making this 
happen?  I see this as being a benefit to both OJ and JEQL, by providing 
some very powerful capabilities to OJ, and by helping JEQL to become 
fully embeddable in a Java system.

If you're interested, contact me and I'll provide more details of the 
how the integration would work, and some ideas for what the UI should be 
able to do.

Martin

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] app development with openJump

[Martin Davis]

; >> Integrated Systems Analysts, Inc.
>>  >>  >>> >>
>>  >>  >>> >>
>>  >>  >>> >>
>>  >>
>> 
>> --
>>  >>  >>> >> Come build with us! The BlackBerry® Developer
>>  >> Conference in SF, CA
>>  >>  >>> >> is the only developer event you need to attend this
>>  >> year. Jumpstart
>>  >>  >>> >> your
>>  >>  >>> >> developing skills, take BlackBerry mobile
>> applications
>>  >> to market and
>>  >>  >>> >> stay
>>  >>  >>> >> ahead of the curve. Join us from November 9-12,
>>  >> 2009. Register
>>  >>  >>> >> now!
>>  >>  >>> >> http://p.sf.net/sfu/devconf
>>  >>  >>> >> ___
>>  >>  >>> >> Jump-pilot-devel mailing list
>>  >>  >>> >> Jump-pilot-devel@lists.sourceforge.net
>> <mailto:Jump-pilot-devel@lists.sourceforge.net>
>>  >> <mailto:Jump-pilot-devel@lists.sourceforge.net
>> <mailto:Jump-pilot-devel@lists.sourceforge.net>>
>>  >>  >>> >>
>>  >>
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>  >>  >>> >>
>>  >>  >>> >>
>>  >>  >>> >
>>  >>  >>> >
>>  >>  >>> >
>>  >>
>> 
>> --
>>  >>  >>> > Come build with us! The BlackBerry® Developer
>>  >> Conference in SF, CA
>>  >>  >>> > is the only developer event you need to attend
>> this year.
>>  >> Jumpstart your
>>  >>  >>> > developing skills, take BlackBerry mobile
>> applications to
>>  >> market and
>>  >>  >>> > stay
>>  >>  >>> > ahead of the curve. Join us from November
>> 9-12, 2009.
>>  >> Register
>>  >>  >>> > now!
>>  >>  >>> > http://p.sf.net/sfu/devconf
>>  >>  >>> > ___
>>  >>  >>> > Jump-pilot-devel mailing list
>>  >>  >>> > Jump-pilot-devel@lists.sourceforge.net
>> <mailto:Jump-pilot-devel@lists.sourceforge.net>
>>  >> <mailto:Jump-pilot-devel@lists.sourceforge.net
>> <mailto:Jump-pilot-devel@lists.sourceforge.net>>
>>  >>  >>> >
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>  >>  >>> >
>>  >>  >>> >
>>  >>  >>>
>>  >>  >>>
>>  >>  >>>
>>  >>
>> 
>> --
>>  >>  >>> Come build with us! The BlackBerry® Developer
>>  >> Conference in SF, CA
>>  >>  >>> is the only developer event you need to attend this
>> year.
>>  >> Jumpstart your
>>  >>  >>> developing skills, take BlackBerry mobile
>> applications to
>>  >> market and stay
>>  >>  >>> ahead of the curve. Join us from November 9-12,
>> 2009.
>>  >> Register
>>  >>  >>> now!
>>  >>  >>> http://p.sf.net/sfu/devconf
>>  >>      >>> ___
>>  >>  >>> Jump-pilot-devel mailing list
>>  >>  >>> Jump-pilot-dev

Re: [JPP-Devel] Source Code For Java Conflation Suite

[Martin Davis]

SS,

That is the official home of JCS, and CVS is the most up-to-date codebase.

JCS (and RoadMatcher, which is built in it) is currently maintained by 
Refractions.  It hasn't been active for a while - but if someone has a 
requirement for extension, and some funding, we're definitely available!

Martin

Sunburned Surveyor wrote:
> Does anyone know where the official home of the JCS code is?
>
> I grabbed a CVS snapshot from here:
>
> http://www.jump-project.org/project.php?PID=JCS&SID=DOWN
>
> Is this the best place to find up-to-date JCS code? Is there any
> organization maintaining JCS?
>
> I didn't see it in the JPP SVN, and thought we might add it there.
>
> The Sunburned Surveyor
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Count distance?

[Martin Davis]

This could also be implemented as a new GeometryFunction (the 
GeometryFunction tool is intentionally designed to be extensible for 
just this kind of need).

It's not clear how fancy you want the UI for this (and the UI is where 
most of the work would go, if it's fancy).  The options in order of 
increasing difficulty are:

- add a GeometryFunction
- add a new menu plugin (which uses the selected feature, a selected 
layer, and outputs a new layer
- a tool (which is invoked via a modal button, and then functions pretty 
much like the menu function above)

The actual geometric processing is pretty trivial.  If you are intending 
to use this on large datasets, you may need a way to restrict the target 
set of features - perhaps by a maximum distance, or by selection, or by 
a drawn Area Of Interest box.



Stefan Steiniger wrote:
> mhm.. I think of that (and you may not be the first who asked something 
> like that) then that would need to be programmed as a new type of mouse 
> tool. A cumbersome approach would be to draw lines from source to target 
>   (attach the point attributes) and then calculate the length of those.
>
> but did you play around with PostGIS? ..because in postgis you could do 
> a SQL query for that - I think.
>
> shall I consider this as a feature request for a new function? (i.e. 
> select a item and select a layer and compute all distances to the 
> selected item and attach those as new attribute)
>
> stefan
>
> Rahkonen Jukka wrote:
>   
>> Hi,
>>
>> Is it possible somehow to count the distance of features from one
>> selected feature?  I guess that just this calculation is done when
>> performing spatial query "is within distance", but could it be possible
>> also to show the distance in addition to making the selection, perhaps
>> by creating a new layer with distance as an attribute?
>>
>> Actually what I am finally aiming at is a tourist guide type query
>> "select n closest restaurants/toilets/banks/etc. from this place ordered
>> by distance.
>>
>> -Jukka Rahkonen-
>>
>> --
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensing option that enables unlimited
>> royalty-free distribution of the report engine for externally facing 
>> server and web deployment.
>> http://p.sf.net/sfu/businessobjects
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>>
>> 
>
> --
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Deegree GML adapter

[Martin Davis]

My KML parsing code is a bit rudimentary at the moment - it supports 
getting the Geometry, and a few attributes like name, description, and 
style name.  But it should be fairly easy to hack into OJ.  It will need 
a StAX API available - I'm using Woodstock right now.

If you'd like to try integrating it I can provide it as it stands.

Sunburned Surveyor wrote:
> Martin,
>
> I  have looked at StAX and planned on using Sun's implementation. My
> code allows you to take information provided by the StAX parser to
> build in memory representations of an element and its content. The
> idea is you only put into RAM what you need. So, for our GML 2
> example, I'll move through the file using StAX, but I will build an
> in-memory representation of each "current" Feature element.
>
> This should give me the low-RAM consumption of an XML pull parsing
> technique, with the convenience of a DOM technique for just the
> current feature element I am working with.
>
> That's what I want to do in theory anyways. I still have to write the
> code and make it work. I'm in the middle of a PNEZD point reader/write
> plug-in for OpenJUMP that I want to get released first.
>
> The Sunburned Surveyor
>
> P.S. - Is your KML parsing code something we could hack to support KML
> in OpenJUMP?
>
>
> On Wed, May 20, 2009 at 1:12 PM, Martin Davis  wrote:
>   
>> Landon,
>>
>> Have you looked into the StAX API for XML pull-parsing?  I'm using it to
>> parse KML, and it makes for fairly easy parser implementation (e.g.
>> recursive descent, which is the simplest for us humans to code up).
>>
>> http://en.wikipedia.org/wiki/StAX
>> http://woodstox.codehaus.org/
>>
>>
>> Sunburned Surveyor wrote:
>> 
>>> I've looked at this problem, and I think it would be possible to write
>>> a fairly simple GML parser that didn't need a schema, as long as the
>>> GML file only contained features of one type. It would be possible to
>>> write the same type of parser for GML files that contain features of
>>> different types, but it would be more work. I would like to start with
>>> the simpler use case first.
>>>
>>> I wrote some simple code to replace JDOM, and a GML 2 parser would be
>>> a good test of it. Perhaps I could rearrange some priorities and get
>>> this busted out in the next couple of weeks.
>>>
>>> Landon
>>>
>>> On Wed, May 20, 2009 at 11:14 AM, Martin Davis  
>>> wrote:
>>>
>>>   
>>>> Has anyone looked at the GeoTools GML reader, to see if it's a
>>>> reasonable thing to include with OJ?
>>>>
>>>> Writing GML readers is not a trivial task - that was why we went with
>>>> the template idea (so as to push the complexity back onto the human).
>>>> There might be some simpler approaches that could be looked at, though -
>>>> such as pre-scanning the GML file to try and deduce the Feature tag,
>>>> attribute tags & types, and the geometry tag.   It would be an
>>>> interesting project...  I'd be surprised if someone hasn't already
>>>> worked on this.  OGR is another possible model to follow - not sure what
>>>> they do for parsing GML.  The thing that seems really difficult to do is
>>>> to analyze the schema and use that to direct the parsing - that is
>>>> basically equivalent to writing a parser generator, which is a
>>>> non-trivial task.
>>>>
>>>> Sunburned Surveyor wrote:
>>>>
>>>> 
>>>>> I understand the concern about adding a big library to OpenJUMP. I do
>>>>> plan on adding CRS capability to OpenJUMP (sometime this year?) and I
>>>>> have already started putting together the dependencies for the CRS
>>>>> code.
>>>>>
>>>>> I wouldn't be against just splitting out the packages we need to use
>>>>> from the bigger deegree Project libraries, as long as this doesn't get
>>>>> ridiculous. I suppose we can see how this goes with the CRS code.
>>>>>
>>>>> I don't know if it is worth integrating the degree libs for the GML
>>>>> parser. I think we can probably whip up our own lightweight solution
>>>>> to this problem.
>>>>>
>>>>> The Sunburned Surveyor
>>>>>
>>>>> On Wed, May 20, 2009 at 1:14 AM, Andreas Schmitz  
>>>>> wrote:
>>>>>

Re: [JPP-Devel] Deegree GML adapter

[Martin Davis]

Landon,

Have you looked into the StAX API for XML pull-parsing?  I'm using it to 
parse KML, and it makes for fairly easy parser implementation (e.g. 
recursive descent, which is the simplest for us humans to code up).

http://en.wikipedia.org/wiki/StAX
http://woodstox.codehaus.org/


Sunburned Surveyor wrote:
> I've looked at this problem, and I think it would be possible to write
> a fairly simple GML parser that didn't need a schema, as long as the
> GML file only contained features of one type. It would be possible to
> write the same type of parser for GML files that contain features of
> different types, but it would be more work. I would like to start with
> the simpler use case first.
>
> I wrote some simple code to replace JDOM, and a GML 2 parser would be
> a good test of it. Perhaps I could rearrange some priorities and get
> this busted out in the next couple of weeks.
>
> Landon
>
> On Wed, May 20, 2009 at 11:14 AM, Martin Davis  
> wrote:
>   
>> Has anyone looked at the GeoTools GML reader, to see if it's a
>> reasonable thing to include with OJ?
>>
>> Writing GML readers is not a trivial task - that was why we went with
>> the template idea (so as to push the complexity back onto the human).
>> There might be some simpler approaches that could be looked at, though -
>> such as pre-scanning the GML file to try and deduce the Feature tag,
>> attribute tags & types, and the geometry tag.   It would be an
>> interesting project...  I'd be surprised if someone hasn't already
>> worked on this.  OGR is another possible model to follow - not sure what
>> they do for parsing GML.  The thing that seems really difficult to do is
>> to analyze the schema and use that to direct the parsing - that is
>> basically equivalent to writing a parser generator, which is a
>> non-trivial task.
>>
>> Sunburned Surveyor wrote:
>> 
>>> I understand the concern about adding a big library to OpenJUMP. I do
>>> plan on adding CRS capability to OpenJUMP (sometime this year?) and I
>>> have already started putting together the dependencies for the CRS
>>> code.
>>>
>>> I wouldn't be against just splitting out the packages we need to use
>>> from the bigger deegree Project libraries, as long as this doesn't get
>>> ridiculous. I suppose we can see how this goes with the CRS code.
>>>
>>> I don't know if it is worth integrating the degree libs for the GML
>>> parser. I think we can probably whip up our own lightweight solution
>>> to this problem.
>>>
>>> The Sunburned Surveyor
>>>
>>> On Wed, May 20, 2009 at 1:14 AM, Andreas Schmitz  wrote:
>>>
>>>   
>>>> Stefan Steiniger wrote:
>>>>
>>>> 
>>>>> Michaël Michaud wrote:
>>>>>
>>>>>   
>>>> Hi,
>>>>
>>>>
>>>> 
>>>>>> Here are my thoughts about the question :
>>>>>> - Andreas is one of the main contributors of the project, so his own
>>>>>> advice about what is good for OpenJUMP is much welcome
>>>>>>
>>>>>> 
>>>> thanks, although I don't feel like I've been contributing much lately...
>>>>
>>>>
>>>> 
>>>>>> - I wouldn't like to see big libraries added to openjump just to be able
>>>>>> to use a few classes of those libraries, but small packages to add
>>>>>> capabities to OJ are OK
>>>>>>
>>>>>> 
>>>> Yes, that's why I'm also hesitating a little (see below).
>>>>
>>>>
>>>> 
>>>>>> - To answer more precisely, It would be interesting to know
>>>>>>if deegree code should be included as a whole or on a per package 
>>>>>> basis
>>>>>>what would be the size and the potential of each package for OpenJUMP
>>>>>>what would be the redundances with existing OJ code (which may need
>>>>>> to clean some parts of existing code...)
>>>>>>
>>>>>> 
>>>> I think that would be fairly difficult and not worth it. Once the GML 
>>>> parsing is
>>>> used, you use a major part of deegree (feature model, CRS, GML model, 
>>>> geometry
>>>> model etc.), so that copying over only required packages makes it virtually

Re: [JPP-Devel] Deegree GML adapter

[Martin Davis]

GIN PGP SIGNATURE-
>> Version: GnuPG v1.4.9 (GNU/Linux)
>>
>> iEYEARECAAYFAkoTu9gACgkQ737OVr+Ru7rdXgCfal7ZpzSc/Jqo6bG3vL4UsGTU
>> AUkAn2ry5cfIpNOfBzJ7T8aFhaOsl0aC
>> =5U1K
>> -END PGP SIGNATURE-
>>
>> --
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensing option that enables
>> unlimited royalty-free distribution of the report engine
>> for externally facing server and web deployment.
>> http://p.sf.net/sfu/businessobjects
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>>
>> 
>
> --
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables 
> unlimited royalty-free distribution of the report engine 
> for externally facing server and web deployment. 
> http://p.sf.net/sfu/businessobjects
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] [Fwd: [jump-pilot - OpenJUMP Functions Problems] BigDecimal to Double class cat exception]

[Martin Davis]

Either

1) fix the SIS DB plugin to use Doubles for Oracle NUMBER, or
2) fix the ShapefileWriter to accept BigDecimal values and convert them 
to doubles.  '

#2 should be pretty easy to do.

Stefan Steiniger wrote:
> any suggestions?
>
>  Original Message 
> Subject:  [jump-pilot - OpenJUMP Functions Problems] BigDecimal to 
> Double class cat exception
> Date: Wed, 20 May 2009 16:30:16 +
> From: SourceForge.net 
> To:   nore...@sourceforge.net
>
>
>
> Read and respond to this message at: 
> https://sourceforge.net/forum/message.php?msg_id=7401466
> By: spatial1234
>
> I am using SIS DB plugin to query the data from oracle database. One of my 
> table
> column is number datatype.
> When I try to save as shpafile it's giving me following exception. Does 
> anybody
> has fix for it?
>
> Here my oracle table structure
>
> create table county
> (county_id  NUMBER,
>  geom   mdsys.sdo_Geometry);
>
> java.lang.ClassCastException: java.math.BigDecimal cannot be cast
> to java.lang.Double
>   at 
> com.vividsolutions.jump.io.ShapefileWriter.writeDbf(ShapefileWriter.java:436
> )
>   at 
> com.vividsolutions.jump.io.ShapefileWriter.write(ShapefileWriter.java:288)
>   at 
> com.vividsolutions.jump.io.datasource.ReaderWriterFileDataSource$1.executeUp
> date(ReaderWriterFileDataSource.java:72)
>   at 
> com.vividsolutions.jump.workbench.datasource.AbstractSaveDatasetAsPlugIn.run
> (AbstractSaveDatasetAsPlugIn.java:33)
>   at 
> com.vividsolutions.jump.workbench.ui.task.TaskMonitorManager$TaskWrapper.run
> (TaskMonitorManager.java:149)
>   at java.lang.Thread.run(Unknown Source)
>
> Thanks,
> Bala
>
> __
> You are receiving this email because you elected to monitor this forum.
> To stop monitoring this forum, login to SourceForge.net and visit: 
> https://sourceforge.net/forum/unmonitor.php?forum_id=729479
>
>
>
> --
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables 
> unlimited royalty-free distribution of the report engine 
> for externally facing server and web deployment. 
> http://p.sf.net/sfu/businessobjects
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] [jts-devel] Re: Question on use cases of JTS trianguation API

[Martin Davis]

Normally in academic papers/textbooks the algorithmic complexity is 
derived symbolically, based on the characteristics and data structures 
used in the algorithm.  It's always seems like a bit of a black art to 
me - the proofs are often much more complicated than the algorithm 
(which may itself be complicated!)

I usually do exactly what Michael has done, and guesstimate it from a 
set of timings.   But note that this provides an estimate of the 
complexity in the average case - the worst-case complexity (the big-O 
expression) is often much worse (eg for the Delaunay incremental 
insertion algorithm it's O(n^2) - but this is rarely or never seen in 
practice).

Stefan Steiniger wrote:
> wow.. those geeky talks ;)
>
> I would like to know much more about Comp Geom.
>
> Can I actually ask how Michael derived the algorithmic complexity 
> empirical? - because if I ever see these things, for instance by M van 
> Kreveld or in some optimiziation books (e.g. Z Michalewicz and DB Fogel 
> 2000)- I don't get how this is really done (and proven - but maybe I 
> just need to read those books in detail).
>
> thank you guys - if you talk, I always can learn some things
> stefan
>
> Martin Davis schrieb:
>   
>> Right, I see the sorting step now.  Out of curiosity, did you check to 
>> see if it was any faster using an array and Collections.sort, rather 
>> than a TreeSet?  I would have thought building a tree was slower than 
>> doing a single sort of an array, followed by removing duplicates by 
>> traversing the array (perhaps by copying only unique points).
>>
>> Interesting algorithm - that would be great to see a reference for this.
>>
>> So this isn't incremental insertion - the classic incremental insertion 
>> adds points randomly, locating their containing triangle, dividing it 
>> into 3 new triangles, and then restoring the Delaunay property by edge 
>> flipping.  The location step is the potentially slow part.  This sounds 
>> similar to the step you use for adding constraints.
>>
>> If you're adding Steiner points along constraint segments, then you have 
>> a Conformal Delaunay. A Constrained Delaunay contains the constraint 
>> edges exactly in the triangulation (and hence is not fully Delaunay).  
>> Shewchuck has a nice explanation:  
>> http://www.cs.cmu.edu/%7Equake/triangle.defs.html#conform
>>
>> Martin
>>
>> Michaël Michaud wrote:
>> 
>>> Hi
>>>   
>>>   
>>>> I should have looked before I wrote - I just found the link you sent a 
>>>> while ago to your code (for others benefit - 
>>>> http://geo.michaelm.free.fr/OpenJUMP/resources/ ).
>>>>
>>>> So you are using Incremental insertion, with a Triangle- based data 
>>>> structure.  It looks like your code handles Constrained Delaunay - or is 
>>>> it Conformal Delaunay?  I'll have to look a bit more to see.
>>>>   
>>>> 
>>>> 
>>> I'm not sure what incremental insertion is.
>>> In my implementation, I sort points before starting the triangulation 
>>> (sorting points is included in my benchmark).
>>> I think this makes a lot of optimisation possible (just have to walk 
>>> through the convex hull using triangle adjacency)
>>> There is also an "incremental" part used for constrained Delaunay 
>>> triangulation as constraints are added to the
>>> triangulation afterwards (I have no benchmark for this part yet, but it 
>>> should be much slower).
>>> While adding constraints, Delaunay property is kept by adding points 
>>> along segments (steiner points ?).
>>> Constrained triangulation is probably even slower due to new points 
>>> insertion.
>>> If you try it, you must use 3d coordinates.
>>>   
>>>   
>>>> Anyway, very impressive timings.  I'm curious to know where the speed 
>>>> different lies.  It could be the point location search, or the data 
>>>> structure manipulation, or perhaps both?
>>>>   
>>>> 
>>>> 
>>> I can try to find back a more precise description of the implementation.
>>>
>>> Michaël
>>>   
>>>   
>>>> Martin Davis wrote:
>>>>   
>>>> 
>>>> 
>>>>> Interesting comparison, Michael.  Is your code online somewhere?  What 
>>>>> algorithm does it use, and what data structure for the triangulation?
>>>>>
>>>>> In the JTS API 

Re: [JPP-Devel] [jts-devel] Re: Question on use cases of JTS trianguation API

[Martin Davis]

Right, I see the sorting step now.  Out of curiosity, did you check to 
see if it was any faster using an array and Collections.sort, rather 
than a TreeSet?  I would have thought building a tree was slower than 
doing a single sort of an array, followed by removing duplicates by 
traversing the array (perhaps by copying only unique points).

Interesting algorithm - that would be great to see a reference for this.

So this isn't incremental insertion - the classic incremental insertion 
adds points randomly, locating their containing triangle, dividing it 
into 3 new triangles, and then restoring the Delaunay property by edge 
flipping.  The location step is the potentially slow part.  This sounds 
similar to the step you use for adding constraints.

If you're adding Steiner points along constraint segments, then you have 
a Conformal Delaunay. A Constrained Delaunay contains the constraint 
edges exactly in the triangulation (and hence is not fully Delaunay).  
Shewchuck has a nice explanation:  
http://www.cs.cmu.edu/%7Equake/triangle.defs.html#conform

Martin

Michaël Michaud wrote:
> Hi
>   
>> I should have looked before I wrote - I just found the link you sent a 
>> while ago to your code (for others benefit - 
>> http://geo.michaelm.free.fr/OpenJUMP/resources/ ).
>>
>> So you are using Incremental insertion, with a Triangle- based data 
>> structure.  It looks like your code handles Constrained Delaunay - or is 
>> it Conformal Delaunay?  I'll have to look a bit more to see.
>>   
>> 
> I'm not sure what incremental insertion is.
> In my implementation, I sort points before starting the triangulation 
> (sorting points is included in my benchmark).
> I think this makes a lot of optimisation possible (just have to walk 
> through the convex hull using triangle adjacency)
> There is also an "incremental" part used for constrained Delaunay 
> triangulation as constraints are added to the
> triangulation afterwards (I have no benchmark for this part yet, but it 
> should be much slower).
> While adding constraints, Delaunay property is kept by adding points 
> along segments (steiner points ?).
> Constrained triangulation is probably even slower due to new points 
> insertion.
> If you try it, you must use 3d coordinates.
>   
>> Anyway, very impressive timings.  I'm curious to know where the speed 
>> different lies.  It could be the point location search, or the data 
>> structure manipulation, or perhaps both?
>>   
>> 
> I can try to find back a more precise description of the implementation.
>
> Michaël
>   
>> Martin Davis wrote:
>>   
>> 
>>> Interesting comparison, Michael.  Is your code online somewhere?  What 
>>> algorithm does it use, and what data structure for the triangulation?
>>>
>>> In the JTS API you don't have to create the triangles as a MultiPolygon 
>>> - that's just provided as a simple option for viewing them in the JTS 
>>> TestBuilder.  In OJ I certainly wouldn't do that - I would split them 
>>> into one Feature per triangle.
>>>
>>> I figured that the JTS code was about O(n*sqrt(n)) as well - although 
>>> the theoretical performance of incremental insertion is actually 
>>> O(n^2)!  But I think this is rarely seen in practice.
>>>
>>> Martin
>>>
>>> Michaël Michaud wrote:
>>>   
>>> 
>>>   
>>>> Hi Martin,
>>>>
>>>> Today, I compared the new JTS triangulation api with the triangulation 
>>>> plugin I wrote some years ago.
>>>> In my tests, I just compared speed for triangulation of a random set 
>>>> of points (no constraint, no real data).
>>>> Measures include initialization, triangulation, and feature(s) creation.
>>>>
>>>> Both libraries worked well. I did not check result correctness.
>>>> Processing time was faster with my code (and ratio between two 
>>>> consecutive figures are always better).
>>>> Of course, triangulation speed is only one thing and may not be the 
>>>> most important. Just want to show that there is still room for 
>>>> improvement.
>>>>  
>>>> In OpenJUMP, memory usage was better with JTS api than with my plugin 
>>>> (1560Mb vs 2033Mb).
>>>> I suppose this is partly due to the number of features created (about 
>>>> 1M features in my case, only one feature in your case).
>>>> On the other hand, as I told you  before, playing with a MultiPolygon 
>>>> composed of 1M triangles is not easy.
>>>>

Re: [JPP-Devel] [jts-devel] Re: Question on use cases of JTS trianguation API

[Martin Davis]

Michael,

I should have looked before I wrote - I just found the link you sent a 
while ago to your code (for others benefit - 
http://geo.michaelm.free.fr/OpenJUMP/resources/ ).

So you are using Incremental insertion, with a Triangle- based data 
structure.  It looks like your code handles Constrained Delaunay - or is 
it Conformal Delaunay?  I'll have to look a bit more to see.

Anyway, very impressive timings.  I'm curious to know where the speed 
different lies.  It could be the point location search, or the data 
structure manipulation, or perhaps both?


Martin Davis wrote:
> Interesting comparison, Michael.  Is your code online somewhere?  What 
> algorithm does it use, and what data structure for the triangulation?
>
> In the JTS API you don't have to create the triangles as a MultiPolygon 
> - that's just provided as a simple option for viewing them in the JTS 
> TestBuilder.  In OJ I certainly wouldn't do that - I would split them 
> into one Feature per triangle.
>
> I figured that the JTS code was about O(n*sqrt(n)) as well - although 
> the theoretical performance of incremental insertion is actually 
> O(n^2)!  But I think this is rarely seen in practice.
>
> Martin
>
> Michaël Michaud wrote:
>   
>> Hi Martin,
>>
>> Today, I compared the new JTS triangulation api with the triangulation 
>> plugin I wrote some years ago.
>> In my tests, I just compared speed for triangulation of a random set 
>> of points (no constraint, no real data).
>> Measures include initialization, triangulation, and feature(s) creation.
>>
>> Both libraries worked well. I did not check result correctness.
>> Processing time was faster with my code (and ratio between two 
>> consecutive figures are always better).
>> Of course, triangulation speed is only one thing and may not be the 
>> most important. Just want to show that there is still room for 
>> improvement.
>>  
>> In OpenJUMP, memory usage was better with JTS api than with my plugin 
>> (1560Mb vs 2033Mb).
>> I suppose this is partly due to the number of features created (about 
>> 1M features in my case, only one feature in your case).
>> On the other hand, as I told you  before, playing with a MultiPolygon 
>> composed of 1M triangles is not easy.
>> In OJ, with a MultiPolygon of 1M triangles, the user interface do not 
>> respond anymore and I could not explode the MultiPolygon (if I had to 
>> implement a plugin, I would probably make it possible to explode it 
>> before it is displayed).
>>
>> I did not look at your implementation, but I tried to find its 
>> complexity in an empiric way. I found that your algo has about a 
>> n*sqrt(n) complexity, but this deduction may be due to measurement 
>> errors :
>> MM : n*log(n)*2.4E-6
>> MD : n*sqrt(n)*0.1E-6
>>
>> Even if it is not yet the fastest, I have no doubt JTS triangulation 
>> api will soon be a reference in the java world.
>> Thank you to share your excellent work.
>>
>> Michaël
>>
>> Figures (times in sec for sets from 50 000 to 1 000 000 points)
>>
>>
>>
>>
>>
>>  
>>
>>
>> Michaël Michaud a écrit :
>> 
>>> Hi Martin,
>>>
>>> You may already know the benchmark done by Erwan's team with some 
>>> java implementations 
>>> (http://conference.osgeo.org/index.php/foss4g/2008/paper/view/282/177)
>>> It eventually shows the triangulator I have written a few years ago 
>>> (available on http://geo.michaelm.free.fr/OpenJUMP/resources/) is 
>>> very fast (I have to add it is not 100% robust as it sometimes fails 
>>> for large datasets  - more than 100k points)
>>> They also wrote a more recent paper about their new implementation 
>>> for orbisgis : 
>>> http://hal.archives-ouvertes.fr/docs/00/32/95/03/PDF/CDT-paper.pdf
>>>
>>> Now about your question :
>>>
>>> INPUT
>>> - should be able to input ponctual (sites) , lineal (breaklines), 
>>> polygonal geometries (points and breaklines to be extracted)
>>> - collection of coordinates
>>>
>>> INPUT/OUTPUT
>>> - in my plugin, I decided that when the input was a single polygon, 
>>> the output should be a triangulation containing only triangles inside 
>>> the polygon (not all triangles inside the convex hull)
>>> (may not concern the low level api)
>>>
>>> OUTPUT
>>> - in my Triangulation class, I decided to return a simple 
>>> Coordinate[] array containing n*3 objects (elements 0, 1 and 2 
>>> composing the first tri

Re: [JPP-Devel] [jts-devel] Re: Question on use cases of JTS trianguation API

[Martin Davis]

One other thing  the JTS API supports computing a Conformal Delaunay 
Triangulation as well.  This is done using the Incremental Insertion 
algorithm to refine the triangulation.  So this is a bit of a constraint 
on the design and implementation.  I'm not sure if CDTs are supported by 
other Delaunay algorithms.

Since your algorithm seems to be so much faster, it's good to have both 
available!

Michaël Michaud wrote:
> Hi Martin,
>
> Today, I compared the new JTS triangulation api with the triangulation 
> plugin I wrote some years ago.
> In my tests, I just compared speed for triangulation of a random set 
> of points (no constraint, no real data).
> Measures include initialization, triangulation, and feature(s) creation.
>
> Both libraries worked well. I did not check result correctness.
> Processing time was faster with my code (and ratio between two 
> consecutive figures are always better).
> Of course, triangulation speed is only one thing and may not be the 
> most important. Just want to show that there is still room for 
> improvement.
>  
> In OpenJUMP, memory usage was better with JTS api than with my plugin 
> (1560Mb vs 2033Mb).
> I suppose this is partly due to the number of features created (about 
> 1M features in my case, only one feature in your case).
> On the other hand, as I told you  before, playing with a MultiPolygon 
> composed of 1M triangles is not easy.
> In OJ, with a MultiPolygon of 1M triangles, the user interface do not 
> respond anymore and I could not explode the MultiPolygon (if I had to 
> implement a plugin, I would probably make it possible to explode it 
> before it is displayed).
>
> I did not look at your implementation, but I tried to find its 
> complexity in an empiric way. I found that your algo has about a 
> n*sqrt(n) complexity, but this deduction may be due to measurement 
> errors :
> MM : n*log(n)*2.4E-6
> MD : n*sqrt(n)*0.1E-6
>
> Even if it is not yet the fastest, I have no doubt JTS triangulation 
> api will soon be a reference in the java world.
> Thank you to share your excellent work.
>
> Michaël
>
> Figures (times in sec for sets from 50 000 to 1 000 000 points)
>
>
>
>
>
>  
>
>
> Michaël Michaud a écrit :
>> Hi Martin,
>>
>> You may already know the benchmark done by Erwan's team with some 
>> java implementations 
>> (http://conference.osgeo.org/index.php/foss4g/2008/paper/view/282/177)
>> It eventually shows the triangulator I have written a few years ago 
>> (available on http://geo.michaelm.free.fr/OpenJUMP/resources/) is 
>> very fast (I have to add it is not 100% robust as it sometimes fails 
>> for large datasets  - more than 100k points)
>> They also wrote a more recent paper about their new implementation 
>> for orbisgis : 
>> http://hal.archives-ouvertes.fr/docs/00/32/95/03/PDF/CDT-paper.pdf
>>
>> Now about your question :
>>
>> INPUT
>> - should be able to input ponctual (sites) , lineal (breaklines), 
>> polygonal geometries (points and breaklines to be extracted)
>> - collection of coordinates
>>
>> INPUT/OUTPUT
>> - in my plugin, I decided that when the input was a single polygon, 
>> the output should be a triangulation containing only triangles inside 
>> the polygon (not all triangles inside the convex hull)
>> (may not concern the low level api)
>>
>> OUTPUT
>> - in my Triangulation class, I decided to return a simple 
>> Coordinate[] array containing n*3 objects (elements 0, 1 and 2 
>> composing the first triangle...)
>>  I'm not that sure, but I think this structure just contained 
>> references to input coordinates (memory-friendly)
>> - i would prefer a collection of Linestrings or a collection of 
>> Polygons than a MultiLinestring or MultiPolygon, because I'm not sure 
>> a mutigeometry of one million elements is easy to deal with (spatial 
>> indexation inefficient for example). Moreover, individual geometries 
>> can give the oppurtunity to keep the tin structure with links between 
>> elements represented as attributes, or to compute height, slope, 
>> orientation on every individual triangle and keep them as attributes. 
>> I understand why a Tin structure is interesting (no duplicate), but 
>> not a multi-geometry.
>>
>> My 2 cents
>>
>> Michaël
>>
>>
>> Martin Davis a écrit :
>>> To those that are interested in the upcoming JTS triangulation API, 
>>> a question:
>>>
>>> What type of input and output structures would you find useful?
>>>
>>> C

Re: [JPP-Devel] [jts-devel] Re: Question on use cases of JTS trianguation API

[Martin Davis]

Interesting comparison, Michael.  Is your code online somewhere?  What 
algorithm does it use, and what data structure for the triangulation?

In the JTS API you don't have to create the triangles as a MultiPolygon 
- that's just provided as a simple option for viewing them in the JTS 
TestBuilder.  In OJ I certainly wouldn't do that - I would split them 
into one Feature per triangle.

I figured that the JTS code was about O(n*sqrt(n)) as well - although 
the theoretical performance of incremental insertion is actually 
O(n^2)!  But I think this is rarely seen in practice.

Martin

Michaël Michaud wrote:
> Hi Martin,
>
> Today, I compared the new JTS triangulation api with the triangulation 
> plugin I wrote some years ago.
> In my tests, I just compared speed for triangulation of a random set 
> of points (no constraint, no real data).
> Measures include initialization, triangulation, and feature(s) creation.
>
> Both libraries worked well. I did not check result correctness.
> Processing time was faster with my code (and ratio between two 
> consecutive figures are always better).
> Of course, triangulation speed is only one thing and may not be the 
> most important. Just want to show that there is still room for 
> improvement.
>  
> In OpenJUMP, memory usage was better with JTS api than with my plugin 
> (1560Mb vs 2033Mb).
> I suppose this is partly due to the number of features created (about 
> 1M features in my case, only one feature in your case).
> On the other hand, as I told you  before, playing with a MultiPolygon 
> composed of 1M triangles is not easy.
> In OJ, with a MultiPolygon of 1M triangles, the user interface do not 
> respond anymore and I could not explode the MultiPolygon (if I had to 
> implement a plugin, I would probably make it possible to explode it 
> before it is displayed).
>
> I did not look at your implementation, but I tried to find its 
> complexity in an empiric way. I found that your algo has about a 
> n*sqrt(n) complexity, but this deduction may be due to measurement 
> errors :
> MM : n*log(n)*2.4E-6
> MD : n*sqrt(n)*0.1E-6
>
> Even if it is not yet the fastest, I have no doubt JTS triangulation 
> api will soon be a reference in the java world.
> Thank you to share your excellent work.
>
> Michaël
>
> Figures (times in sec for sets from 50 000 to 1 000 000 points)
>
>
>
>
>
>  
>
>
> Michaël Michaud a écrit :
>> Hi Martin,
>>
>> You may already know the benchmark done by Erwan's team with some 
>> java implementations 
>> (http://conference.osgeo.org/index.php/foss4g/2008/paper/view/282/177)
>> It eventually shows the triangulator I have written a few years ago 
>> (available on http://geo.michaelm.free.fr/OpenJUMP/resources/) is 
>> very fast (I have to add it is not 100% robust as it sometimes fails 
>> for large datasets  - more than 100k points)
>> They also wrote a more recent paper about their new implementation 
>> for orbisgis : 
>> http://hal.archives-ouvertes.fr/docs/00/32/95/03/PDF/CDT-paper.pdf
>>
>> Now about your question :
>>
>> INPUT
>> - should be able to input ponctual (sites) , lineal (breaklines), 
>> polygonal geometries (points and breaklines to be extracted)
>> - collection of coordinates
>>
>> INPUT/OUTPUT
>> - in my plugin, I decided that when the input was a single polygon, 
>> the output should be a triangulation containing only triangles inside 
>> the polygon (not all triangles inside the convex hull)
>> (may not concern the low level api)
>>
>> OUTPUT
>> - in my Triangulation class, I decided to return a simple 
>> Coordinate[] array containing n*3 objects (elements 0, 1 and 2 
>> composing the first triangle...)
>>  I'm not that sure, but I think this structure just contained 
>> references to input coordinates (memory-friendly)
>> - i would prefer a collection of Linestrings or a collection of 
>> Polygons than a MultiLinestring or MultiPolygon, because I'm not sure 
>> a mutigeometry of one million elements is easy to deal with (spatial 
>> indexation inefficient for example). Moreover, individual geometries 
>> can give the oppurtunity to keep the tin structure with links between 
>> elements represented as attributes, or to compute height, slope, 
>> orientation on every individual triangle and keep them as attributes. 
>> I understand why a Tin structure is interesting (no duplicate), but 
>> not a multi-geometry.
>>
>> My 2 cents
>>
>> Michaël
>>
>>
>> Martin Davis a écrit :
>>> To those that are interested in the upcoming JTS triangulation API, 
>>&