Hi,
I have a weird error when trying to split one dataset into new layers by an
attribute value. The reason seems to be that I have an attribute named as
"teksti" and somehow OpenJUMP is translating it to "TEXT" on-the-fly. If I
rename the column the splitting succeeds. A minimal sample with
That's really weird! A language revenge?
2013/2/14 Rahkonen Jukka
> Hi,
>
> I have a weird error when trying to split one dataset into new layers by
> an attribute value. The reason seems to be that I have an attribute named
> as "teksti" and somehow OpenJUMP is translating it to "TEXT" on-the-
Jukka:
That is really weird. I can see the error is being thrown by the
FeatureSchema class. Can you tell us what "Tunnistamaton
ominaisuustiedon nimi" means? It is part of the stack trace.
Landon
On Thu, Feb 14, 2013 at 1:50 AM, Giuseppe Aruta wrote:
> That's really weird! A language revenge?
Landon: he did! last sentence.. ede
On 14.02.2013 16:41, Landon Blake wrote:
> Jukka:
>
> That is really weird. I can see the error is being thrown by the
> FeatureSchema class. Can you tell us what "Tunnistamaton
> ominaisuustiedon nimi" means? It is part of the stack trace.
>
> Landon
>
> On
Oops.
Thanks Ede.
It doesn't seem like OJ should be doing any translation of attribute
names, does it? Could this be a bug in the SplitLayer plug-in?
Landon
On Thu, Feb 14, 2013 at 7:47 AM, wrote:
> Landon: he did! last sentence.. ede
>
> On 14.02.2013 16:41, Landon Blake wrote:
>> Jukka:
>>
Jukka,
Can you file a bug report? I don't use Sextante, but it looks like the
error is being thrown by the Sextante code when the GUI for the tool
you are trying to open is being constructed by OJ.
Landon
On Mon, Feb 11, 2013 at 7:40 AM, Rahkonen Jukka
wrote:
> Hi,
>
> Java 7 appeared into my c
MM:
I think you solution of attaching an "undoable command" to a layer is
an elegant solution to the problem we discussed.
I'm thinking it would be cool at some point to allow the user to set
the start and end points of a group of undoable commands. That way we
could remove one "group" of command
I have just given a look at the class ExtractLayersByAttribute
I think that line:
String attributeValue = feature.getAttribute("TEXT").toString();
I think should be
String attributeValue = feature.getAttribute(TEXT).toString();
2013/2/14 Landon Blake
> Oops.
>
> Thanks Ede.
>
> It doesn't
No bug on that class Landon,
It seems that who developed that class (Skjumper?) considered to allow
translation on two classes name LAYER and TEXT, the later to allow an
authomatic labeling on features with TEXT (or other language like
TESTO or TEKSTI.
I would check also if this codes
org.openjum
Hi Peppe,
I am not sure if you can do the changes without knowing about the SRID/
project coordinate system.
For instance if someone loads a shapefile (or raster) with geographic
coordinates stored your change would still be showing meters (or do I
misunderstand your proposal?). Also, what happ
Really Stefan these were my main doubts.
- if someone loads a shapefile (or raster) with geographic coordinates
stored your change would still be showing meters (or do I misunderstand
your proposal?).
Right now Coordinatelistmetrics always shows units as if they were metric
even on geographic coor
Hi Jukka,
Should be fixed in r3253
Michaël
Hi,
I have a weird error when trying to split one dataset into new layers by an attribute value. The
reason seems to be that I have an attribute named as "teksti" and somehow OpenJUMP is
translating it to "TEXT" on-the-fly. If I rename the column
MM:
Was this a translation problem, or a bug in the code?
SS
On Thu, Feb 14, 2013 at 1:05 PM, Michaël Michaud
wrote:
> Hi Jukka,
>
> Should be fixed in r3253
>
> Michaël
>
> Hi,
>
> I have a weird error when trying to split one dataset into new layers by an
> attribute value. The reason seems
Hi to all,
When you are adding any shape file into OpenJUMP by default it get colored. I
just want to know the code for how a shape file will get colored by default?
and Code for measuring scale?
Regards,
D Pardhu.
--
F
14 matches
Mail list logo