hi,
is there any reason why you can only create fieldnames with max. 11 characters
in the attribut table?
ok, you can create one with more than 11, but when you save and re-open the
layer, the fieldname is cut to 11 characters...
carl--
Hi,
Did you try saving in JUMP GML format? ESRI shapefiles have their own limits
which do not come from JUMP.
-Jukka Rahkonen-
Lähettäjä: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Puolesta Carl
Grönniger (entera)
Lähetetty: 16. huhtikuuta
hi,
yes, the other formats don't cut off the fieldnames.
but it's not a general problem because in arcview you can create shps with
longer fieldnames.
does anybody know if it's set somewhere in the shapefilewriter in openjump or
somewhere else?
otherwise i'm not really able to work with oj becau
Dear OpenJumper,
We are working at IRSTV on a CDT api in JAVA. The api will integrate some
functionalities like insert polygon with hole, node, line and skeleton
refinement. It's a transposition of my thesis work in pure java.
Feel free to send me a mail.
R1.
2008/4/16, Geoffrey G Roy <[EMAIL
Strange, I thought that dBASE file format is what limits the length of the name
field. Have a look at for example
http://www.geocities.com/geoff_wass/dBASE/GaryWhite/dBASE/FAQ/qformt.htm
There you can read that dBASE file format at least up to version 5 gives only
11 bytes for field name. I w
Hi Carl,
I just created a new Shapefile in ArcCatalog 8.3 and added fields named
Customer_Data, Customer_info, and Customer_name. ArcCatalog issued an error
message and changed the fields to Customer_D, Customer_i, and Customer_n.
The limit is actually 10 characters
(terminated by 00h) accordin
Erwan,
What is the CDT that you refer to?
The Sunburned Surveyor
On Wed, Apr 16, 2008 at 5:10 AM, erwan bocher <[EMAIL PROTECTED]> wrote:
> Dear OpenJumper,
>
> We are working at IRSTV on a CDT api in JAVA. The api will integrate some
> functionalities like insert polygon with hole, node, line
Geoff,
I don't think we made the official jump to Java 1.6 just yet. (This
doesn't mean one of us didn't accidentally introduce a dependency on
1.6 into the nightly build.)
Stefan can probably confirm this for us.
I wouldn't mind a discussion of when we can make the jump to 1.6. I
would like to
oh yes.. I forgot Erwans work on the TANATO plugin.
http://www.projet-sigle.org/spip.php?rubrique17
Unfortunately Erwan did not wrote who is doing the work at IRSTV
(http://orbisgis.cerma.archi.fr/?page_id=40)
I hope it is not confusing, so we need to lay out what should be
different (i.e. CDT 2
The OSGeo originally had only 9 slots for the 30 student applications,
including the two from OpenJUMP. (One by Chris for TIN support, and
one by Leandro for visual geoprocessing models.)
The OSGeo was able to negotiate 11 more slots for a total of 20 slots!
That means that both our student appli
Erwan,
Is there any chance this page exists in English?:
http://www.projet-sigle.org/spip.php?article35
If not, perhaps you could provide a link to the source code for Chris
and I? It would be great to build on any work that has already been
done on TIN support by you and your team.
The Sunburn
CDT = Constrained Delaunay Triangulation ;)
a triangulation where some edges are feature edges (i.e. the wall of a
building is an edge of the triangulation, which it would probably not be
if only points (wall corners) are considered.
sorry for using short terms (we should have introduced them m
1.6 is only available for intel osx... none for ppc osx, fyi.
On Apr 16, 2008, at 11:18 AM, Sunburned Surveyor wrote:
> Geoff,
>
> I don't think we made the official jump to Java 1.6 just yet. (This
> doesn't mean one of us didn't accidentally introduce a dependency on
> 1.6 into the nightly bui
I thought I would add my two cents on Java 1.6. SkyJUMP currently uses Java
1.6.0_01. I recently considered upgrading to Java 1.6.0_05, but found that
it was VERY much slower. Everything was slower. The GUI was visibly more
sluggish. Of course, it may be only on my particular processor, but it
Hi SS,
>It sounds like we need to give it some more time.
I think so. There is almost no value added to require Java 1.6. OJ can
still run under it fine if someone wants to. It is still a lot faster than
1.5 if you stick to the 1.6.0_01 release.
Larry
On Wed, Apr 16, 2008 at 12:36 PM, Sunbur
hip hip - hooray!!!
I thank you too for organizing all this stuff (and I am sorry that I too
often have been very late on the track, but moving to new countries and
environments takes time).
stefan
PS: nobody requires that you donate your stipend. It is work you do...
so you should benefit fr
btw...
I also have problems with OpenJUMP on my new machine (it runs 1.6.0_03).
When I move windows around it is really slow in terms of updating the
screen compared to my 1.5 version on my laptop. Interestingly an old
JUMP 1.2 /OpenJUMP version from 2006 (before we did rendering
optimization)
I think the windows installer for jre1.6.0_01 is called
jre-6u1-windows-i586-p-s.exe if you can still find a copy.
On Wed, Apr 16, 2008 at 12:50 PM, Stefan Steiniger <[EMAIL PROTECTED]>
wrote:
> btw...
>
> I also have problems with OpenJUMP on my new machine (it runs 1.6.0_03).
> When I move win
Excellent news!!
Congratulations to all!!
Count with me to help in the project, as we talked...
2008/4/16, Stefan Steiniger <[EMAIL PROTECTED]>:
>
> hip hip - hooray!!!
>
> I thank you too for organizing all this stuff (and I am sorry that I too
> often have been very late on the track, but movin
That is good information Larry. Eric also mentioned on another thread
that 1.6 isn't available on all Mac processors just yet. It sounds
like we need to give it some more time.
The Sunburned Surveyor
On Wed, Apr 16, 2008 at 10:33 AM, Larry Becker <[EMAIL PROTECTED]> wrote:
> I thought I would add
I'm getting ready to test my code for i18n formatted measurement
values in OpenJUMP. This will allow OpenJUMP to present distance,
angle/direction, area, and volume measurements to users in a format
controlled by the users locale and the selected unit system. I'd like
to ask for suggestions on how
I remembered someone (I think Jon Aquino) mentioning that an object
called a Registry could be used to access data throughout OpenJUMP. I
was skimming the Javadoc for the Registry class and I think I can use
it to allow plug-ins to contribute unit systems.
In this scenario the unit system contribu
SS,
This is exactly the kind of use case the Registry was meant to support.
It is a system-wide repository for non-deleteable value objects of
specific categories. Your scenario for development sounds just fine to me.
Martin
Sunburned Surveyor wrote:
> I remembered someone (I think Jon Aquin
Hei,
to me it sounds still a bit abstract (i.e. not sure what you
implementation would all encompass in terms of classes and so on)
but as martin agrees I have no problems with that.
btw. I would actually prefer to integrate it in the core directly - as
it is a needed feature. however, not sure
Hei,
sorry Paul for the late response. I am reading some of the left over
emails lately.
I think your idea sounds reasonable and makes sense to me.
However, I would hear first a comment by Andreas (because they have the
new lib and also have done the WMS/WFS stuff).
What you have been referein
Hei Larry,
as I am reading the left over emails from last week:
any news on this issue?
stefan
Larry Becker schrieb:
> It looks like the code needs more work. I'm just using it as a quick
> fix for now.
>
> thanks,
> Larry
>
> On Fri, Apr 4, 2008 at 2:22 PM, Sunburned Surveyor
> <[EMAIL PRO
Hi,
I'm not sure to understand how you want to implement the Unit System
plugin. From my point of view, the problem has two "sides" :
- one side is the unit system Coordinates refer to. In an ideal world,
this parameter should be included in the "Coordinate Reference System"
associated with the
27 matches
Mail list logo
