[Geoserver-devel] More on catalog UUID usage vs system integration

GeoServer GeoServer Developer
1

Hi,
remember the thread where the usage of UUIDs to identify catalog elements was
discussed? I have more :slight_smile:

Basically, the UUIDs idea allwed a central catalog system to identify
layers in a
range of GeoServer instances, with different admins, plugin set and versions,
hosted by different departments of a large organization.

Now, the next step is going back from the central catalog to the GeoServers
and being able to do stuff against them using the UUID only (the layer name
is unsuitable as it can change over time and might be duplicated, and so on).

This would require two more changes:
1) ability to expose UUIDs in the REST api too, side by side with the atom link.
2) ability to perform OGC requests using the UUID in place of the layer name

1) is a bit at odds with the REST linked-ness, but only so much, since the links
would not be removed, we'd just expose the id property which is today hidden.
I don't see any harm in exposing it, but it could also be exposed conditionally
based on a system property or global configuration

2) would allow someone to do a request like
    request=GetMap&layers=550e8400-e29b-41d4-a716-446655440000,84febf07-4884-4136-acf6-5e6d432af03d&....
I had a look at how this could be done in a plugin of some sorts, but dispatcher
callbacks are often too late in the parsing game to perform the lookup.
The most direct approach would be to either modify all the KVP parsers to
use a fallback, or to modify the catalog so that getLayerByName and friends
also do a lookup by id if a certain flag is raised (system integration flag?).
The latter would also allow the system integration to work on rest api lookups,
e..g, geoserver/rest/layers/550e8400-e29b-41d4-a716-446655440000
(but only if the request is explicit, we would not list the ids otherwise)

I've tried to get both of the above with some sort of pluggable
behavior but it seems
that by their nature they are better placed in the core code instead.

Suggestions?

Cheers
Andrea

--
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

2

Hmmm… not so sure. I totally understand the use case but am weary about starting to publish what are now internal identifiers in all of our service apis. It would kind of be a wide spreading changes… we would have to update all services to accept an id where there now they expect a name, and maintain that moving forward as we add new services, etc…

What about a separate service/endpoint/whatever whose job it would be to “resolve” an identifier into the actual representation of the object. So something like:

GET /geoserver/…/id/550e8400-e29b-41d4-a716-446655440000

Would give you back whatever catalog object that id links to. WIth that you have enough info to make whatever service call you need to.

On Thu, Jun 7, 2012 at 2:08 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
remember the thread where the usage of UUIDs to identify catalog elements was
discussed? I have more :slight_smile:

Basically, the UUIDs idea allwed a central catalog system to identify
layers in a
range of GeoServer instances, with different admins, plugin set and versions,
hosted by different departments of a large organization.

Now, the next step is going back from the central catalog to the GeoServers
and being able to do stuff against them using the UUID only (the layer name
is unsuitable as it can change over time and might be duplicated, and so on).

This would require two more changes:

  1. ability to expose UUIDs in the REST api too, side by side with the atom link.

  2. ability to perform OGC requests using the UUID in place of the layer name

  3. is a bit at odds with the REST linked-ness, but only so much, since the links
    would not be removed, we’d just expose the id property which is today hidden.
    I don’t see any harm in exposing it, but it could also be exposed conditionally
    based on a system property or global configuration

  4. would allow someone to do a request like
    request=GetMap&layers=550e8400-e29b-41d4-a716-446655440000,84febf07-4884-4136-acf6-5e6d432af03d&…
    I had a look at how this could be done in a plugin of some sorts, but dispatcher
    callbacks are often too late in the parsing game to perform the lookup.
    The most direct approach would be to either modify all the KVP parsers to
    use a fallback, or to modify the catalog so that getLayerByName and friends
    also do a lookup by id if a certain flag is raised (system integration flag?).
    The latter would also allow the system integration to work on rest api lookups,
    e…g, geoserver/rest/layers/550e8400-e29b-41d4-a716-446655440000
    (but only if the request is explicit, we would not list the ids otherwise)

I’ve tried to get both of the above with some sort of pluggable
behavior but it seems
that by their nature they are better placed in the core code instead.

Suggestions?

Cheers
Andrea

–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

3

On Thu, Jun 7, 2012 at 5:34 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hmmm... not so sure. I totally understand the use case but am weary about
starting to publish what are now internal identifiers in all of our service
apis. It would kind of be a wide spreading changes.. we would have to update
all services to accept an id where there now they expect a name, and
maintain that moving forward as we add new services, etc...

Yep, that's why I was suggesting to do that at the catalog level, to make
it service independent.
It would not be too hard if we had a "catalog decorator" extension, but
we don't right now.
Do you see problems in adding something like that in the 2.2.x series?

What about a separate service/endpoint/whatever whose job it would be to
"resolve" an identifier into the actual representation of the object. So
something like:

GET /geoserver/.../id/550e8400-e29b-41d4-a716-446655440000

Would give you back whatever catalog object that id links to. WIth that you
have enough info to make whatever service call you need to.

I see, however that would result in a ton of round trips between the master
catalog and the single GeoServer instances.

If exposing the ids in REST config, even just with a flag, is not acceptable,
what kind of extension point might get me there?
It does not seem easy, a flag enabling issuing the id in the resources
would be quite a bit easier.

Long story short, if this cannot be done in core I'm looking into rolling a
"system integration" extension, but that needs some hooks to do its work.
The key is that whatever we do should be available as an official GeoServer
functionality, or an official plugin.

Cheers
Andrea

--
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

4

On Thu, Jun 7, 2012 at 9:03 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Jun 7, 2012 at 5:34 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hmmm… not so sure. I totally understand the use case but am weary about
starting to publish what are now internal identifiers in all of our service
apis. It would kind of be a wide spreading changes… we would have to update
all services to accept an id where there now they expect a name, and
maintain that moving forward as we add new services, etc…

Yep, that’s why I was suggesting to do that at the catalog level, to make
it service independent.
It would not be too hard if we had a “catalog decorator” extension, but
we don’t right now.
Do you see problems in adding something like that in the 2.2.x series?

I like the idea of a catalog decorator, keeps things nice and clean in one place rather than have it creep down into CatalogImpl and the CatalogFacade. Also makes it easy to turn it on/off if need be. For the recent local workspace stuff i added a base class for catalog decorators called AbstractCatalogDecorator.

I see no problems on 2.2.x… might want to wait for 2.2 official to go out the door and shoot for 2.2.1? Not a strong opinon on that though.

What about a separate service/endpoint/whatever whose job it would be to
“resolve” an identifier into the actual representation of the object. So
something like:

GET /geoserver/…/id/550e8400-e29b-41d4-a716-446655440000

Would give you back whatever catalog object that id links to. WIth that you
have enough info to make whatever service call you need to.

I see, however that would result in a ton of round trips between the master
catalog and the single GeoServer instances.

If exposing the ids in REST config, even just with a flag, is not acceptable,
what kind of extension point might get me there?
It does not seem easy, a flag enabling issuing the id in the resources
would be quite a bit easier.

Long story short, if this cannot be done in core I’m looking into rolling a
“system integration” extension, but that needs some hooks to do its work.
The key is that whatever we do should be available as an official GeoServer
functionality, or an official plugin.

Right… so a few choices:

  1. Just turn id’s on by default and call it a day.

  2. Same as (1) but being a bit more complete about it and have this slot into the existing api nicely. Basically adding a new endpoint(s), or modify the existing resource to accept an id from clients as well. So be able to do things like:

GET /geoserver/rest/featuretypes/
GET /geoserver/rest/stores/

And I guess one resource to rule them all, since we may not know in advance what the type of the object is.

GET /geoserver/rest/catalog/objects/

  1. Just turn id’s when some configuration flag is set, as you suggested.

All in all I do like (2) but I recognize it represents the most work as well :slight_smile:

Cheers
Andrea

–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

On Thu, Jun 7, 2012 at 6:35 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

It would not be too hard if we had a "catalog decorator" extension, but
we don't right now.
Do you see problems in adding something like that in the 2.2.x series?

I like the idea of a catalog decorator, keeps things nice and clean in one
place rather than have it creep down into CatalogImpl and the CatalogFacade.
Also makes it easy to turn it on/off if need be. For the recent local
workspace stuff i added a base class for catalog decorators
called AbstractCatalogDecorator.

Yep, I guess they could be extension points, and would be built one on
top of the other based on their priority.

I see no problems on 2.2.x... might want to wait for 2.2 official to go out
the door and shoot for 2.2.1? Not a strong opinon on that though.

Yep, that sounds feasible.

Right... so a few choices:

1. Just turn id's on by default and call it a day.

2. Same as (1) but being a bit more complete about it and have this slot
into the existing api nicely. Basically adding a new endpoint(s), or modify
the existing resource to accept an id from clients as well. So be able to do
things like:

GET /geoserver/rest/featuretypes/<id>
GET /geoserver/rest/stores/<id>

And I guess one resource to rule them all, since we may not know in advance
what the type of the object is.

GET /geoserver/rest/catalog/objects/<id>

3. Just turn id's when some configuration flag is set, as you suggested.

All in all I do like (2) but I recognize it represents the most work as well

If we go 2) it seems something that would be always on, as part of the
standard API, or am I missing something?
I could go for that.

Cheers
Andrea

--
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

6

On Thu, Jun 7, 2012 at 2:01 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Jun 7, 2012 at 6:35 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

It would not be too hard if we had a “catalog decorator” extension, but
we don’t right now.
Do you see problems in adding something like that in the 2.2.x series?

I like the idea of a catalog decorator, keeps things nice and clean in one
place rather than have it creep down into CatalogImpl and the CatalogFacade.
Also makes it easy to turn it on/off if need be. For the recent local
workspace stuff i added a base class for catalog decorators
called AbstractCatalogDecorator.

Yep, I guess they could be extension points, and would be built one on
top of the other based on their priority.

Makes sense to me.

I see no problems on 2.2.x… might want to wait for 2.2 official to go out
the door and shoot for 2.2.1? Not a strong opinon on that though.

Yep, that sounds feasible.

Right… so a few choices:

  1. Just turn id’s on by default and call it a day.

  2. Same as (1) but being a bit more complete about it and have this slot
    into the existing api nicely. Basically adding a new endpoint(s), or modify
    the existing resource to accept an id from clients as well. So be able to do
    things like:

GET /geoserver/rest/featuretypes/
GET /geoserver/rest/stores/

And I guess one resource to rule them all, since we may not know in advance
what the type of the object is.

GET /geoserver/rest/catalog/objects/

  1. Just turn id’s when some configuration flag is set, as you suggested.

All in all I do like (2) but I recognize it represents the most work as well

If we go 2) it seems something that would be always on, as part of the
standard API, or am I missing something?
I could go for that.

Yeah, that is what I am thinking. At first I was weary of the idea of publishing the identifiers but I can’t think of a good reason not to. One thing we will have to be sure of as we roll new catalog facade implementations is that they should make sure id’s should are UUID’s.

Cheers
Andrea

–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

7

On Fri, Jun 8, 2012 at 4:44 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

If we go 2) it seems something that would be always on, as part of the
standard API, or am I missing something?
I could go for that.

Yeah, that is what I am thinking. At first I was weary of the idea of
publishing the identifiers but I can't think of a good reason not to. One
thing we will have to be sure of as we roll new catalog facade
implementations is that they should make sure id's should are UUID's.

Works for me.
Generally speaking there is nothing really demanding usage of UUIDs
Geoserver wise, they are just a nice global way to get ids that works
in a system integration setting.
Wondering, should we make this a requirement or just a recommendation?

Recommendations have the nasty side effect of making people have to
deal with two different cases, UUIDs or not, both on the server and client
side.
I would go for making it a requirement for the sake of simplicity, but
I'm open to have it be just recommended

Cheers
Andrea

--
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

8

On Fri, Jun 8, 2012 at 1:42 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Jun 8, 2012 at 4:44 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

If we go 2) it seems something that would be always on, as part of the
standard API, or am I missing something?
I could go for that.

Yeah, that is what I am thinking. At first I was weary of the idea of
publishing the identifiers but I can’t think of a good reason not to. One
thing we will have to be sure of as we roll new catalog facade
implementations is that they should make sure id’s should are UUID’s.

Works for me.
Generally speaking there is nothing really demanding usage of UUIDs
Geoserver wise, they are just a nice global way to get ids that works
in a system integration setting.
Wondering, should we make this a requirement or just a recommendation?

Recommendations have the nasty side effect of making people have to
deal with two different cases, UUIDs or not, both on the server and client
side.
I would go for making it a requirement for the sake of simplicity, but
I’m open to have it be just recommended

I think a requirement is fine… most environments, databases, languages, etc… have the ability to generate UUID’s. If so should we do it full force and actually try to model it in the interfaces and have id be a java.util.UUID? Or just a javadoc?

Cheers
Andrea

–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

9

on a related note, in WMS we have AuthorityURL and Identifier, and I guess they’re defined in the spec for similar system integration use cases.
Would it be an option to instead have a (configurable) default authority URL and its identifier defaulting to the LayerInfo id?
Or do you really need the id exposure to spread over all the catalog objects and services?

2c/
Gabriel

On Thu, Jun 7, 2012 at 6:08 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
remember the thread where the usage of UUIDs to identify catalog elements was
discussed? I have more :slight_smile:

Basically, the UUIDs idea allwed a central catalog system to identify
layers in a
range of GeoServer instances, with different admins, plugin set and versions,
hosted by different departments of a large organization.

Now, the next step is going back from the central catalog to the GeoServers
and being able to do stuff against them using the UUID only (the layer name
is unsuitable as it can change over time and might be duplicated, and so on).

This would require two more changes:

  1. ability to expose UUIDs in the REST api too, side by side with the atom link.

  2. ability to perform OGC requests using the UUID in place of the layer name

  3. is a bit at odds with the REST linked-ness, but only so much, since the links
    would not be removed, we’d just expose the id property which is today hidden.
    I don’t see any harm in exposing it, but it could also be exposed conditionally
    based on a system property or global configuration

  4. would allow someone to do a request like
    request=GetMap&layers=550e8400-e29b-41d4-a716-446655440000,84febf07-4884-4136-acf6-5e6d432af03d&…
    I had a look at how this could be done in a plugin of some sorts, but dispatcher
    callbacks are often too late in the parsing game to perform the lookup.
    The most direct approach would be to either modify all the KVP parsers to
    use a fallback, or to modify the catalog so that getLayerByName and friends
    also do a lookup by id if a certain flag is raised (system integration flag?).
    The latter would also allow the system integration to work on rest api lookups,
    e…g, geoserver/rest/layers/550e8400-e29b-41d4-a716-446655440000
    (but only if the request is explicit, we would not list the ids otherwise)

I’ve tried to get both of the above with some sort of pluggable
behavior but it seems
that by their nature they are better placed in the core code instead.

Suggestions?

Cheers
Andrea

–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

10

On Fri, Jun 8, 2012 at 10:58 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

on a related note, in WMS we have AuthorityURL and Identifier, and I guess they’re defined in the spec for similar system integration use cases.
Would it be an option to instead have a (configurable) default authority URL and its identifier defaulting to the LayerInfo id?
Or do you really need the id exposure to spread over all the catalog objects and services?

hmm I guess you do, and by central catalog system you mean geoserver catalog and not CSW. So forget about the above.

2c/
Gabriel

On Thu, Jun 7, 2012 at 6:08 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
remember the thread where the usage of UUIDs to identify catalog elements was
discussed? I have more :slight_smile:

Basically, the UUIDs idea allwed a central catalog system to identify
layers in a
range of GeoServer instances, with different admins, plugin set and versions,
hosted by different departments of a large organization.

Now, the next step is going back from the central catalog to the GeoServers
and being able to do stuff against them using the UUID only (the layer name
is unsuitable as it can change over time and might be duplicated, and so on).

This would require two more changes:

  1. ability to expose UUIDs in the REST api too, side by side with the atom link.

  2. ability to perform OGC requests using the UUID in place of the layer name

  3. is a bit at odds with the REST linked-ness, but only so much, since the links
    would not be removed, we’d just expose the id property which is today hidden.
    I don’t see any harm in exposing it, but it could also be exposed conditionally
    based on a system property or global configuration

  4. would allow someone to do a request like
    request=GetMap&layers=550e8400-e29b-41d4-a716-446655440000,84febf07-4884-4136-acf6-5e6d432af03d&…
    I had a look at how this could be done in a plugin of some sorts, but dispatcher
    callbacks are often too late in the parsing game to perform the lookup.
    The most direct approach would be to either modify all the KVP parsers to
    use a fallback, or to modify the catalog so that getLayerByName and friends
    also do a lookup by id if a certain flag is raised (system integration flag?).
    The latter would also allow the system integration to work on rest api lookups,
    e…g, geoserver/rest/layers/550e8400-e29b-41d4-a716-446655440000
    (but only if the request is explicit, we would not list the ids otherwise)

I’ve tried to get both of the above with some sort of pluggable
behavior but it seems
that by their nature they are better placed in the core code instead.

Suggestions?

Cheers
Andrea

–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

11

On Sat, Jun 9, 2012 at 4:00 AM, Gabriel Roldan <groldan@anonymised.com> wrote:

hmm I guess you do, and by central catalog system you mean geoserver catalog
and not CSW. So forget about the above.

I mean a sort of CSW, but not implementing said protocol and
registering more than
just layers. So yep, I'd need all the catalog objects to have a
globally unique id.

That said, the idea of exposing the uuid via the wms capabilities
might indeed be
useful for catalog... not sure, I don't know how catalogues handle that

Cheers
Andrea

--
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf