gdms format on windows mobile

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

gdms format on windows mobile

moovida
Hi developers,
in the painful process to find a spatially indexed format accessible
from java and working on windows mobile (yes, Trimble Juno has this
nasty thing on it), some good man suggested me to have a look at gdms.
I wasn't aware of it and gave it a look.

It would be amazing to be able to use an indexed gdms format to access the data.

There is a problem though. Windows Mobile Java, the CDC/Foundation
Profile, is very limited. I would compare it with a downsized java
1.4.
So there is no nice stuff such as annotations, which gdms uses at
least in connection with jaxb.

My knowledge in gdms is too low to be able to judge the outcome, but I
guess trying that path might be a loss of time. I would be glad if
some of you developers could give me some hint or advice.

I was hoping to find an older version maybe based on 1.4 or at least
no generics, but I figured that also oldest tag found in the repo
(2.2) has 1.6 dependencies.

Any advice would be greatly appreciated.

Thanks,
Andrea
Reply | Threaded
Open this post in threaded view
|

Re: gdms format on windows mobile

Alexis.G
Hi moovida,

As far as I can tell, you can get rid of most of the explicit
dependencies on Java 1.6 that are not directly in index code. What is
really important for you are really the GDMS core functionalities,
particularly the index, and even more precisely the DiskRTree. You
will maybe interested in the GDMS driver part too, in order to store
your tables (ie geometries and their attributes) on disk.

Particularly, you won't need most of the external drivers, and you'll
be able not to use the JAXB part. if we consider the core
functionalities of GDMS, the main, really important dependency, is
JTS. And as it has been pointed to you on the JTS mailing list, JTS is
compatible with th VM you want to use.

If we consider the dependency graph of GDMS, what will be really
important for your use is JTS, and maybe one of libraries called CTS
(that is used for our projection operations). There are dependencies
to other libraries that can be removed really fast (postgis jdbc
driver, a library to read csv...), and some others that can be removed
with a bit more work, even if that will not threaten the GDMS
mechanism (log4j, junit (but you'll loose our unit tests ;-)) )

After that, you'll notice that we use annotations a lot - because they
are useful to us ^_^. They can be removed in most the cases without
any problem. We use generics too, and some other post 1.4 stuff... And
as I've never work with pre-1.6 JVM, I can't tell how much time it
would take to replace them :-(

If you have any questions about how GDMS works, don't hesitate - this
list is here for that ;-)

Best regards,

Alexis.

PS : nice to hear that I'm a "good man" :-p
Reply | Threaded
Open this post in threaded view
|

Re: gdms format on windows mobile

Antoine Gourlay
In reply to this post by moovida
Hi Andrea,

It is nice to see developers come and ask challenging questions :-)

Tu complete Alexis's answer, you could actually take only the index implementation from Gdms. It all depends on what you need:
 - a disk-based spatial index
 - both a spatial file format and a disk-based spatial index

The spatial index used in Gdms (the library, not the file format), a disk-based R-Tree, is not specific to any file format. It only deals with JTS envelopes and thus can index gdms files as well as shapefile or VRML files, for example. That is the whole point of the abstraction layer of Gdms.

If all you want it the index, this is a good thing: the DiskRTree has no dependency against the gdms core, or the gdms file driver for that matter. It needs JTS though, in order to compute the insections of envelopes. You could just use that part.
On the other hand, if you want to use the Gdms file driver, there are a few more things to do, as Alexis explained...

As for the port of the index to Java 1.4 or equivalent, the current implementation of the index uses generics but that can be removed easily. It uses Java NIO too, which came with Java 1.4, but I do not know if it supported on the mobile version, but I doubt it. I cannot really tell you the cost of migrating to the old Java IO implementation, I have not used it enough...

I hope this helps :-)

Regards,
Antoine
Reply | Threaded
Open this post in threaded view
|

Re: gdms format on windows mobile

moovida
Alexis, Antoine,
thanks so much for the much appreciated help.

The project I am working on has a tight deadline and works on a bad OS
(yes you are right nio is not supported), so I will go for a simple
JTS index dump, following the idea of the DiskRTree. Porting the whole
thing might get really tricky, since I don't even need attribute
support.

BTW I think I just fell in love with the gdms format and I will
approach it for another open source project I have that is in deep
need of something like that and has a better OS (www.geopaparazzi.eu).
As far as I see that would make it possible to enable shapefile and
different other formats on the smartphone.
I am wondering why no other project used it? Or maybe eveyone is using
it and I just do not know (usually is goes like that). :)

I am wondering if there is also something like a rendering engine
architecture (layer based) that could be used to render in different
projections? I am not talking about reprojecting, but currently our
renderer does only lat/long, which makes it impossible to load our own
data (ex. ortophoto).

Thanks to both for the good suggestions, I will have to review them as
I go through the code.

Best regards,
Andrea

> It is nice to see developers come and ask challenging questions :-)
>
> Tu complete Alexis's answer, you could actually take only the index
> implementation from Gdms. It all depends on what you need:
>  - a disk-based spatial index
>  - both a spatial file format and a disk-based spatial index
>
> The spatial index used in Gdms (the library, not the file format), a
> disk-based R-Tree, is not specific to any file format. It only deals with
> JTS envelopes and thus can index gdms files as well as shapefile or VRML
> files, for example. That is the whole point of the abstraction layer of
> Gdms.
>
> If all you want it the index, this is a good thing: the DiskRTree has no
> dependency against the gdms core, or the gdms file driver for that matter.
> It needs JTS though, in order to compute the insections of envelopes. You
> could just use that part.
> On the other hand, if you want to use the Gdms file driver, there are a
> few more things to do, as Alexis explained...
>
> As for the port of the index to Java 1.4 or equivalent, the current
> implementation of the index uses generics but that can be removed easily. It
> uses Java NIO too, which came with Java 1.4, but I do not know if it
> supported on the mobile version, but I doubt it. I cannot really tell you
> the cost of migrating to the old Java IO implementation, I have not used it
> enough...
>
> I hope this helps :-)
>
> Regards,
> Antoine
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://orbisgis.3871844.n2.nabble.com/gdms-format-on-windows-mobile-tp6767006p6767691.html
> To start a new topic under OrbisGIS Developers, email
> [hidden email]
> To unsubscribe from OrbisGIS Developers, click here.
Reply | Threaded
Open this post in threaded view
|

Re: gdms format on windows mobile

moovida
In reply to this post by Antoine Gourlay
Hi developers,

> The project I am working on has a tight deadline and works on a bad OS
> (yes you are right nio is not supported), so I will go for a simple
> JTS index dump, following the idea of the DiskRTree. Porting the whole
> thing might get really tricky, since I don't even need attribute
> support.

guess that kept anyone from answering my following questions. :)

> BTW I think I just fell in love with the gdms format and I will
> approach it for another open source project I have that is in deep
> need of something like that and has a better OS (www.geopaparazzi.eu).
> As far as I see that would make it possible to enable shapefile and
> different other formats on the smartphone.
> I am wondering why no other project used it? Or maybe eveyone is using
> it and I just do not know (usually is goes like that). :)

While I should be able to try the above (hopefully without too much
trouble), I am really interested and asking to revise the following
question, if possible:

> I am wondering if there is also something like a rendering engine
> architecture (layer based) that could be used to render in different
> projections? I am not talking about reprojecting, but currently our
> renderer does only lat/long, which makes it impossible to load our own
> data (ex. ortophoto).

Is this something possible to extract from the rest and use under
android? If yes, can someone give me an entry point?

Thanks, cheers,
Andrea


> Thanks to both for the good suggestions, I will have to review them as
> I go through the code.
>
> Best regards,
> Andrea
>
>> It is nice to see developers come and ask challenging questions :-)
>>
>> Tu complete Alexis's answer, you could actually take only the index
>> implementation from Gdms. It all depends on what you need:
>>  - a disk-based spatial index
>>  - both a spatial file format and a disk-based spatial index
>>
>> The spatial index used in Gdms (the library, not the file format), a
>> disk-based R-Tree, is not specific to any file format. It only deals with
>> JTS envelopes and thus can index gdms files as well as shapefile or VRML
>> files, for example. That is the whole point of the abstraction layer of
>> Gdms.
>>
>> If all you want it the index, this is a good thing: the DiskRTree has no
>> dependency against the gdms core, or the gdms file driver for that matter.
>> It needs JTS though, in order to compute the insections of envelopes. You
>> could just use that part.
>> On the other hand, if you want to use the Gdms file driver, there are a
>> few more things to do, as Alexis explained...
>>
>> As for the port of the index to Java 1.4 or equivalent, the current
>> implementation of the index uses generics but that can be removed easily. It
>> uses Java NIO too, which came with Java 1.4, but I do not know if it
>> supported on the mobile version, but I doubt it. I cannot really tell you
>> the cost of migrating to the old Java IO implementation, I have not used it
>> enough...
>>
>> I hope this helps :-)
>>
>> Regards,
>> Antoine
>>
>> ________________________________
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://orbisgis.3871844.n2.nabble.com/gdms-format-on-windows-mobile-tp6767006p6767691.html
>> To start a new topic under OrbisGIS Developers, email
>> [hidden email]
>> To unsubscribe from OrbisGIS Developers, click here.
>