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 probably
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 dat
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
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, m
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 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 probably be
> sufficient.
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 wrote:
>
> Larry,
>
> If you can let me know when the commit is complete, I will make a
> fresh build
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 t
I think our project is fresh out of snooty graphics designers. :[
SS
On Tue, May 26, 2009 at 10:55 AM, Christopher 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
>
> --- On Tu
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 wrote:
>
>
> --- On Tue, 5/26/09, Andreas Schmitz wrote:
>> Of course, the elevation values are lost anyway
>> when
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
wrote:
> I second Stefan's motion to commit. :]
>
> After all that discussion, it would be a shame not to move forward!
>
> Landon
>
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 wrote:
> Hei Larry,
>
>
>> BTW, I do have a mod that tracks changes to BasicFeature ready to
>> commit that addresses all of the
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 wrote:
>
> Hi,
>
> I updated my sources, but c
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 co
13 matches
Mail list logo