Option 1 is intriguing, because it would be a very good mean of
exchanging geo data, a single file with everything inside, very good!!!
Maybe an ibrid solution were the project is itself store inside the H2
database, while each Layer can be internal or external would be even
better. Also you
Hi Michaël,
It seems that (fr) horizontal has increased to 824 while vertical has
reduced to 504. What was it before?
This is what I was afraid of. Optimization of multi-language dialogs is
very tricky.
regards,
Larry
On 5/27/09, Michaël Michaud michael.mich...@free.fr wrote:
Hi,
I
I second Stefan's motion to commit. :]
After all that discussion, it would be a shame not to move forward!
Landon
On Tue, May 26, 2009 at 2:37 PM, Stefan Steiniger sst...@geo.uzh.ch wrote:
Hei Larry,
BTW, I do have a mod that tracks changes to BasicFeature ready to
commit that addresses
I don't see any reason why we couldn't work more with Z values. It
just hasn't been done extensively to date.
The Sunburned Surveyor
On Tue, May 26, 2009 at 10:53 AM, Christopher infinitye...@yahoo.com wrote:
--- On Tue, 5/26/09, Andreas Schmitz schm...@lat-lon.de wrote:
Of course, the
I think our project is fresh out of snooty graphics designers. :[
SS
On Tue, May 26, 2009 at 10:55 AM, Christopher infinitye...@yahoo.com wrote:
It is for me ;)
Still, the icons could use the gentle massage of a snooty graphics designer
to fully fit into the Mac experience :)
Christopher,
This was a good thread topic, and you did a nice job in outlining our
options. My personal vote is also for Option 3. This option would fit
the best into my personal use of OpenJUMP, and I agree it would be the
simplest to implement.
In order to be truly useful, it might make sense
Larry,
If you can let me know when the commit is complete, I will make a
fresh build available online.
Landon
On Wed, May 27, 2009 at 7:28 AM, Sunburned Surveyor
sunburned.surve...@gmail.com wrote:
I second Stefan's motion to commit. :]
After all that discussion, it would be a shame not to
I did the commit last night. I haven't commited the plugin to test it yet.
The new nightly snapshot is working great, so that will probably be
sufficient.
Larry
On 5/27/09, Sunburned Surveyor sunburned.surve...@gmail.com wrote:
Larry,
If you can let me know when the commit is complete, I
Oops. I forgot that our nightly build was working once again!
Thanks Larry.
SS
On Wed, May 27, 2009 at 8:01 AM, Larry Becker becker.la...@gmail.com wrote:
I did the commit last night. I haven't commited the plugin to test it yet.
The new nightly snapshot is working great, so that will
I had already planned some sort of in-OJ, simplified, seamless, database
management. That is what integration means to me. At the very beginning, it
will probably just be a collection of menu items, then be expanded to include
the context menus of layers, and, if I get to project-as-database,
Sunburned Surveyor wrote:
Hi,
I don't see any reason why we couldn't work more with Z values. It
just hasn't been done extensively to date.
yes, I agree. In principle, it should not be so difficult. But my quick research
showed that the deegree conversion process that creates JTS geometries
Hi,
I second Paolo in most of his comments :
Option 1 would be great for data/project exchange. Including project
information (layer styles) in the database would be great also, but it
may be difficult to manage style definitions in both xml files and
database. About references to external
Another factor to consider is embedded H2 vs server H2. Embedded is faster
so it should probably be used for option 1 and default use. Personally, I'm
more excited about the ability to collaborate with other users using server
H2. The connection strings control which is used so there is
13 matches
Mail list logo
