[Geotools-devel] [JIRA] (GEOT-5163) Curved text not correctly rendered when translated/displaced in PDF output

[JIRA]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Hervé Minko created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5163 
 
 
 
   Curved text not correctly rendered when translated/displaced in PDF output  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 12.0, 10.8 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 render 
 
 
 

Created:
 

 06/Jul/15 10:04 AM 
 
 
 

Priority:
 
  High 
 
 
 

Reporter:
 
 Hervé Minko 
 
 
 
 
 
 
 
 
 
 
I create a own PDF output conataining a WMS map. For that I have to translate/shift the WMS picture within my PDF container. A translation is therefore applied to the whole map content in order to displace the generated pdf map to my wiewport.  
It works fine, but not for the curved text. The translation seems not to be applied to all of them. This issue is obviously similar or related to GEOS-6975 (for multiline texts). 
 
 
 
 
 
 
 
 
 
 
 
 

 
   

[Geotools-devel] [JIRA] (GEOT-5164) SOLR data store bbox support works only under english locale

[Andrea Aime [Administrator] (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Andrea Aime [Administrator] created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5164 
 
 
 
  SOLR data store bbox support works only under english locale  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 
 Andrea Aime [Administrator] 
 
 
 

Components:
 

 SOLR 
 
 
 

Created:
 

 06/Jul/15 10:28 AM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Andrea Aime [Administrator] 
 
 
 
 
 
 
 
 
 
 
Usual issue of number formatting/parsing under different languages 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.5-OD-08-001#65007-sha1:1

[Geotools-devel] Speed up Oracle JDBC DataStore initialization (PR #905)

[Sampo Savolainen]

Hi,

Just to let you know, I did a new pull request for GeoTools:
https://github.com/geotools/geotools/pull/905. This pull request speeds up
for example GeoServer startup for setups that heavily use Oracle JDBC
datastores.


 Sampo

-- 
Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolai...@spatineo.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Filters on nested properties don't work in MongoDB datastore

[Stefano Costa]

Hi all,
first of all, a bit of context: with the new MongoDB community plugin,
it is possible to map as (simple) attributes properties that are nested
inside JSON objects.

E.g., from a collection containing documents with the following
structure:

{
"geometry" : {
"type" : "Point",
"coordinates" : [ 2, 2 ]
},
"data" : {
"intProperty" : 2,
"doubleProperty" : 2.2,
"stringProperty" : "two"
}
}
the default schema mapper would map the three nested properties of the
"data" object to three attributes named "properties.intProperty",
"properties.doubleProperty" and "properties.stringProperty".

In theory, it should be possible to apply CQL filters to the value of
such attributes, like "data.stringProperty LIKE 't%'": however, when the
filter is passed as a request parameter in a WMS request to GeoServer,
it doesn't work.
The reason is that "properties.doubleProperty" is translated to
"properties/doubleProperty" by ECQLCompiler (invokes
ECQLFilterBuilder.buildCompoundAttribute() passing it '/' as attribute
path separator), which makes the property a complete stranger to mongo
datastore's collection mapper.
The issue passed unnoticed through unit tests because the test code
builds filters simply by invoking methods on a FilterFactory2
implementation and doesn't go through GeoServer's filter parameter
parsing process, so ECQLCompiler never comes into play.

Now, I could easily fix the issue replacing '/' with '.' when a
PropertyName filter is visited, but first I'd be interested to know if
there's a good reason for the behavior of ECQLCompiler (and also
CQLCompiler, it seems), which at first sight seems a bit odd, at least
to me.

Any comment is highly appreciated.


-- 

Best regards,
Stefano Costa

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==
Dott. Stefano Costa
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate.
Il loro utilizzo è consentito esclusivamente al destinatario del
messaggio, per le finalità indicate nel messaggio stesso. Qualora
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
cortesemente di darcene notizia via e-mail e di procedere alla
distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
Conservare il messaggio stesso, divulgarlo anche in parte,
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
diverse, costituisce comportamento contrario ai principi dettati dal
D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely
for the attention and use of the named addressee(s) and may be
confidential or proprietary in nature or covered by the provisions of
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
Data Protection Code).Any use not in accord with its purpose, any
disclosure, reproduction, copying, distribution, or either
dissemination, either whole or partial, is strictly forbidden except
previous formal approval of the named addressee(s). If you are not the
intended recipient, please contact immediately the sender by
telephone, fax or e-mail and delete the information in this message
that has been received in error. The sender does not give any warranty
or accept liability as the content, accuracy or completeness of sent
messages and accepts no responsibility  for changes made after they
were sent or for other risks which arise as a result of e-mail
transmission, viruses, etc.




--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Filters on nested properties don't work in MongoDB datastore

[Andrea Aime]

On Mon, Jul 6, 2015 at 2:23 PM, Stefano Costa <
stefano.co...@geo-solutions.it> wrote:

> Hi all,
> first of all, a bit of context: with the new MongoDB community plugin,
> it is possible to map as (simple) attributes properties that are nested
> inside JSON objects.
>
> E.g., from a collection containing documents with the following
> structure:
>
> {
> "geometry" : {
> "type" : "Point",
> "coordinates" : [ 2, 2 ]
> },
> "data" : {
> "intProperty" : 2,
> "doubleProperty" : 2.2,
> "stringProperty" : "two"
> }
> }
> the default schema mapper would map the three nested properties of the
> "data" object to three attributes named "properties.intProperty",
> "properties.doubleProperty" and "properties.stringProperty".
>
> In theory, it should be possible to apply CQL filters to the value of
> such attributes, like "data.stringProperty LIKE 't%'": however, when the
> filter is passed as a request parameter in a WMS request to GeoServer,
> it doesn't work.
> The reason is that "properties.doubleProperty" is translated to
> "properties/doubleProperty" by ECQLCompiler (invokes
> ECQLFilterBuilder.buildCompoundAttribute() passing it '/' as attribute
> path separator), which makes the property a complete stranger to mongo
> datastore's collection mapper.
> The issue passed unnoticed through unit tests because the test code
> builds filters simply by invoking methods on a FilterFactory2
> implementation and doesn't go through GeoServer's filter parameter
> parsing process, so ECQLCompiler never comes into play.
>
> Now, I could easily fix the issue replacing '/' with '.' when a
> PropertyName filter is visited, but first I'd be interested to know if
> there's a good reason for the behavior of ECQLCompiler (and also
> CQLCompiler, it seems), which at first sight seems a bit odd, at least
> to me.
>

a.b is translated to a xpath meaning "the b property of the a attribute".
Changing this behavior might break existing users of WFS 2.0 joins (which
use a syntax like alias/property to refer to a property
of one of the feature types being joined).

Wondering if the mongo store can be changed instead?

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

---
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Filters on nested properties don't work in MongoDB datastore

[Jody Garnett]

I am out this week, I am alarmed if geoserver has custom parameter
implementation. It should be a straight up data structure.

When parsing from xml we should have access to better namespace information
from the XML document beyond what can be represented in CQL.

Perhaps you need to translate the Xpath expression used by the filter
parameterName data structure to match your data store internals? That would
be a new feature ...

Jody
On Mon, Jul 6, 2015 at 8:37 AM Andrea Aime 
wrote:

> On Mon, Jul 6, 2015 at 2:23 PM, Stefano Costa <
> stefano.co...@geo-solutions.it> wrote:
>
>> Hi all,
>> first of all, a bit of context: with the new MongoDB community plugin,
>> it is possible to map as (simple) attributes properties that are nested
>> inside JSON objects.
>>
>> E.g., from a collection containing documents with the following
>> structure:
>>
>> {
>> "geometry" : {
>> "type" : "Point",
>> "coordinates" : [ 2, 2 ]
>> },
>> "data" : {
>> "intProperty" : 2,
>> "doubleProperty" : 2.2,
>> "stringProperty" : "two"
>> }
>> }
>> the default schema mapper would map the three nested properties of the
>> "data" object to three attributes named "properties.intProperty",
>> "properties.doubleProperty" and "properties.stringProperty".
>>
>> In theory, it should be possible to apply CQL filters to the value of
>> such attributes, like "data.stringProperty LIKE 't%'": however, when the
>> filter is passed as a request parameter in a WMS request to GeoServer,
>> it doesn't work.
>> The reason is that "properties.doubleProperty" is translated to
>> "properties/doubleProperty" by ECQLCompiler (invokes
>> ECQLFilterBuilder.buildCompoundAttribute() passing it '/' as attribute
>> path separator), which makes the property a complete stranger to mongo
>> datastore's collection mapper.
>> The issue passed unnoticed through unit tests because the test code
>> builds filters simply by invoking methods on a FilterFactory2
>> implementation and doesn't go through GeoServer's filter parameter
>> parsing process, so ECQLCompiler never comes into play.
>>
>> Now, I could easily fix the issue replacing '/' with '.' when a
>> PropertyName filter is visited, but first I'd be interested to know if
>> there's a good reason for the behavior of ECQLCompiler (and also
>> CQLCompiler, it seems), which at first sight seems a bit odd, at least
>> to me.
>>
>
> a.b is translated to a xpath meaning "the b property of the a attribute".
> Changing this behavior might break existing users of WFS 2.0 joins (which
> use a syntax like alias/property to refer to a property
> of one of the feature types being joined).
>
> Wondering if the mongo store can be changed instead?
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> 

Re: [Geotools-devel] Filters on nested properties don't work in MongoDB datastore

[Andrea Aime]

On Mon, Jul 6, 2015 at 2:45 PM, Jody Garnett  wrote:

> I am out this week, I am alarmed if geoserver has custom parameter
> implementation. It should be a straight up data structure.
>

Custom parameter implementation? What is that? There is no such a thing,
not that I know of.
The xpath syntax I was talking about is part of the WFS 2.0 standard, and
it's also commonly used in
complex feature filters, it just so happens that the nesting operator in
ECQL has historically been the "." instead of "/"
(which is interpreted as math a division instead)

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

---
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Filters on nested properties don't work in MongoDB datastore

[Stefano Costa]

Hi Andrea,

Il giorno lun, 06/07/2015 alle 14.36 +0200, Andrea Aime ha scritto:
> On Mon, Jul 6, 2015 at 2:23 PM, Stefano Costa
>  wrote:
> Now, I could easily fix the issue replacing '/' with '.' when
> a
> PropertyName filter is visited, but first I'd be interested to
> know if
> there's a good reason for the behavior of ECQLCompiler (and
> also
> CQLCompiler, it seems), which at first sight seems a bit odd,
> at least
> to me.
> 
> 
> a.b is translated to a xpath meaning "the b property of the a
> attribute".

OK, now it makes sense.

> Changing this behavior might break existing users of WFS 2.0 joins
> (which use a syntax like alias/property to refer to a property
> of one of the feature types being joined).
> 
> 
> Wondering if the mongo store can be changed instead?

Sorry, I wasn't clear, that's what I meant to do: changing the class
FilterToMongo, which is in charge of translating a Filter to a query
object understandable to MongoDB, so that the '/' separator in property
names is converted back to '.'.

Do you foresee this would break anything?

Thanks,
--S

> 
> 
> Cheers
> Andrea
> 


-- 

Best regards,
Stefano Costa

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==
Dott. Stefano Costa
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate.
Il loro utilizzo è consentito esclusivamente al destinatario del
messaggio, per le finalità indicate nel messaggio stesso. Qualora
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
cortesemente di darcene notizia via e-mail e di procedere alla
distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
Conservare il messaggio stesso, divulgarlo anche in parte,
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
diverse, costituisce comportamento contrario ai principi dettati dal
D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely
for the attention and use of the named addressee(s) and may be
confidential or proprietary in nature or covered by the provisions of
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
Data Protection Code).Any use not in accord with its purpose, any
disclosure, reproduction, copying, distribution, or either
dissemination, either whole or partial, is strictly forbidden except
previous formal approval of the named addressee(s). If you are not the
intended recipient, please contact immediately the sender by
telephone, fax or e-mail and delete the information in this message
that has been received in error. The sender does not give any warranty
or accept liability as the content, accuracy or completeness of sent
messages and accepts no responsibility  for changes made after they
were sent or for other risks which arise as a result of e-mail
transmission, viruses, etc.




--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Filters on nested properties don't work in MongoDB datastore

[Andrea Aime]

On Mon, Jul 6, 2015 at 3:20 PM, Stefano Costa <
stefano.co...@geo-solutions.it> wrote:

> Sorry, I wasn't clear, that's what I meant to do: changing the class
> FilterToMongo, which is in charge of translating a Filter to a query
> object understandable to MongoDB, so that the '/' separator in property
> names is converted back to '.'.
>
> Do you foresee this would break anything?
>
>
It's a bit of a hack, but as long as the mongodb store only publishes
simple features,
it should work.

As an alternative solution, it might be cleaner if the mongo store
published nested
attributes using a different separator, like _ (it must be a valid part of
a xml element
name). I guess doing that might increase significantly clashes with valid
chars in the
mongo property names, forcing you to keep a in memory mapping between the
native names and the published ones.

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

---
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5165) MongoDB datastore: attribute names should not contain dot nor colon characters

[Stefano Costa (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Stefano Costa created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5165 
 
 
 
  MongoDB datastore: attribute names should not contain dot nor colon characters  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 14-M0 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 06/Jul/15 5:16 PM 
 
 
 

Environment:
 
 
Linux Fedora 21 64-bit Oracle JDK 1.8.0.45 MongoDB 2.6.10 GeoTools/GeoServer 14-SNAPSHOT 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Stefano Costa 
 
 
 
 
 
 
 
 
 
 
The default schema mapper maps nested properties to attribute names using the dot-notation, so, for example, a collection containing documents with the following structure: 

 
{
"geometry" : {
"type" : "Point",
"coordinates" : [ 2, 2 ]
},
"data" : {
"intProperty" : 2,
"doubleProperty" : 2.2,
"stringProperty" : "two"
}
}
 

 
would correspond to a schema with three attributes, "data.intProperty", "data.doubleProperty" and "data.stringProperty". This however raises issues when a CQL filter on the attribute is added to e.g. a WMS request, because the attribute name is translated to

Re: [Geotools-devel] Filters on nested properties don't work in MongoDB datastore

[Stefano Costa]

Il giorno lun, 06/07/2015 alle 15.26 +0200, Andrea Aime ha scritto:
> On Mon, Jul 6, 2015 at 3:20 PM, Stefano Costa
>  wrote:
> Sorry, I wasn't clear, that's what I meant to do: changing the
> class
> FilterToMongo, which is in charge of translating a Filter to a
> query
> object understandable to MongoDB, so that the '/' separator in
> property
> names is converted back to '.'.
> 
> Do you foresee this would break anything?
> 
> 
> 
> It's a bit of a hack, but as long as the mongodb store only publishes
> simple features, 
> it should work.
> 
> 
> As an alternative solution, it might be cleaner if the mongo store
> published nested 
> attributes using a different separator, like _ (it must be a valid
> part of a xml element
> name). I guess doing that might increase significantly clashes with
> valid chars in the
> mongo property names, forcing you to keep a in memory mapping between
> the
> native names and the published ones.

Turns out it was not as bas as it looked, since the Mongo datastore
implementation already stores the full path to the property (using "."
notation for nested properties) in the feature type's userData map (key
"mapping"), so the attribute's local name can be manipulated as we see
fit: the collection mapper will always be able to get back to the
original name by reading the mapping information.
I patched MongoInferredMapper, which is in charge of analyzing a mongo
collection and deriving a feature type from it, so that before an
attribute is added to the feature type, its name if passed to a
encodeFieldName() function, which takes care of replacing problematic
characters in it (so far, I'm replacing '.' with '_' and ':' with '-',
the latter one to avoid issues writing features to XML).

I can see two drawbacks with this approach

1. attributes are being renamed in a way that may puzzle the user, who
will have to check the generated schema to be able to write valid
filters.
2. manually crafted schemas may still be affected by the issue: perhaps
the schema reader should throw an error (or at least a warning) if
invalid characters are detected in attribute names?

Pull request is here:
https://github.com/geotools/geotools/pull/908

I can try and write a test if needed.

Thanks for any feedback,
--SC


> 
> 
> Cheers
> Andrea
> 
> 
> -- 
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
> 
> 
> 
> Ing. Andrea Aime 
> 
> @geowolf
> Technical Lead
> 
> 
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
> 
> 
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
> 
> 
> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
> 
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate.
> Il loro utilizzo è consentito esclusivamente al destinatario del
> messaggio, per le finalità indicate nel messaggio stesso. Qualora
> riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
> cortesemente di darcene notizia via e-mail e di procedere alla
> distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
> Conservare il messaggio stesso, divulgarlo anche in parte,
> distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
> diverse, costituisce comportamento contrario ai principi dettati dal
> D.Lgs. 196/2003.
> 
>  
> 
> The information in this message and/or attachments, is intended solely
> for the attention and use of the named addressee(s) and may be
> confidential or proprietary in nature or covered by the provisions of
> privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
> Data Protection Code).Any use not in accord with its purpose, any
> disclosure, reproduction, copying, distribution, or either
> dissemination, either whole or partial, is strictly forbidden except
> previous formal approval of the named addressee(s). If you are not the
> intended recipient, please contact immediately the sender by
> telephone, fax or e-mail and delete the information in this message
> that has been received in error. The sender does not give any warranty
> or accept liability as the content, accuracy or completeness of sent
> messages and accepts no responsibility  for changes made after they
> were sent or for other risks which arise as a result of e-mail
> transmission, viruses, etc.
> 
> 
> 
> 
> ---

-- 

Best regards,
Stefano Costa

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==
Dott. Stefano Costa
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-

Re: [Geotools-devel] SLD Stroke Dasharray Property

[Nuno Oliveira]

Hi,

> The principle is not exactly the same as linecap and linejoin are single 
> values, while a dasharray is an array of values.

You're right my bad ...

> I believe that's why Jody was expecting a Expression[], one expression for 
> each float/double value to be returned. 
> This is more in line with the existing API than assuming a single string that 
> then needs to be tokenized 
> using the comma as a separator.

I assumed that an SLD property should always be mapped to a single expression. 
So should I consider that a dash-array 
property could be mapped to several expressions ?

Best regards,

Nuno Oliveira

Le dimanche 05 juillet 2015 à 09:38 +0100, Andrea Aime a écrit :
> On Fri, Jul 3, 2015 at 8:51 PM, Nuno Oliveira
>  wrote:
> Thanks for your feedback.
> 
> I'm a bit lost about his one 
> 
> I follow the same principie of others methods in that class,
> for example:
> 
> public static String lineLinecap(LineSymbolizer
> symbolizer) ...
> public static String lineLinejoin(LineSymbolizer
> symbolizer) ...
> 
> 
> The principle is not exactly the same as linecap and linejoin are
> single values,
> while a dasharray is an array of values.
> I believe that's why Jody was expecting a Expression[], one expression
> for
> each float/double value to be returned. This is more in line with the
> existing
> API than assuming a single string that then needs to be tokenized
> using the comma
> as a separator
> 
> 
> Cheers
> Andrea
> 
> 
> 
> 
> -- 
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
> 
> 
> 
> Ing. Andrea Aime 
> 
> @geowolf
> Technical Lead
> 
> 
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
> 
> 
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
> 
> 
> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
> 
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate.
> Il loro utilizzo è consentito esclusivamente al destinatario del
> messaggio, per le finalità indicate nel messaggio stesso. Qualora
> riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
> cortesemente di darcene notizia via e-mail e di procedere alla
> distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
> Conservare il messaggio stesso, divulgarlo anche in parte,
> distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
> diverse, costituisce comportamento contrario ai principi dettati dal
> D.Lgs. 196/2003.
> 
>  
> 
> The information in this message and/or attachments, is intended solely
> for the attention and use of the named addressee(s) and may be
> confidential or proprietary in nature or covered by the provisions of
> privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
> Data Protection Code).Any use not in accord with its purpose, any
> disclosure, reproduction, copying, distribution, or either
> dissemination, either whole or partial, is strictly forbidden except
> previous formal approval of the named addressee(s). If you are not the
> intended recipient, please contact immediately the sender by
> telephone, fax or e-mail and delete the information in this message
> that has been received in error. The sender does not give any warranty
> or accept liability as the content, accuracy or completeness of sent
> messages and accepts no responsibility  for changes made after they
> were sent or for other risks which arise as a result of e-mail
> transmission, viruses, etc.
> 
> 
> 
> 
> ---




--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Reminder: GeoTools / GeoServer Meeting at 19:30 UTC on Tuesday

[Ben Caradoc-Davies]

GeoTools / GeoServer committee meeting on Skype at 19:30 UTC on Tuesday:
http://www.timeanddate.com/worldclock/fixedtime.html?msg=GeoTools+%2F+GeoServer+Meeting&year=2015&month=7&day=7&hour=19&min=30&sec=0&ah=1

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Filters on nested properties don't work in MongoDB datastore

[Jody Garnett]

Looks like we are getting past the "GeoServer's filter parameter parsing
process" vs XPath question.

Can I get a clarification on how MongoDB works: should it be publishing
these as "properties.intProperty" or just "intProperty"?



--
Jody Garnett

On 6 July 2015 at 08:23, Stefano Costa 
wrote:

> Hi all,
> first of all, a bit of context: with the new MongoDB community plugin,
> it is possible to map as (simple) attributes properties that are nested
> inside JSON objects.
>
> E.g., from a collection containing documents with the following
> structure:
>
> {
> "geometry" : {
> "type" : "Point",
> "coordinates" : [ 2, 2 ]
> },
> "data" : {
> "intProperty" : 2,
> "doubleProperty" : 2.2,
> "stringProperty" : "two"
> }
> }
> the default schema mapper would map the three nested properties of the
> "data" object to three attributes named "properties.intProperty",
> "properties.doubleProperty" and "properties.stringProperty".
>
> In theory, it should be possible to apply CQL filters to the value of
> such attributes, like "data.stringProperty LIKE 't%'": however, when the
> filter is passed as a request parameter in a WMS request to GeoServer,
> it doesn't work.
> The reason is that "properties.doubleProperty" is translated to
> "properties/doubleProperty" by ECQLCompiler (invokes
> ECQLFilterBuilder.buildCompoundAttribute() passing it '/' as attribute
> path separator), which makes the property a complete stranger to mongo
> datastore's collection mapper.
> The issue passed unnoticed through unit tests because the test code
> builds filters simply by invoking methods on a FilterFactory2
> implementation and doesn't go through GeoServer's filter parameter
> parsing process, so ECQLCompiler never comes into play.
>
> Now, I could easily fix the issue replacing '/' with '.' when a
> PropertyName filter is visited, but first I'd be interested to know if
> there's a good reason for the behavior of ECQLCompiler (and also
> CQLCompiler, it seems), which at first sight seems a bit odd, at least
> to me.
>
> Any comment is highly appreciated.
>
>
> --
>
> Best regards,
> Stefano Costa
>
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
> Dott. Stefano Costa
> Senior Software Engineer
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate.
> Il loro utilizzo è consentito esclusivamente al destinatario del
> messaggio, per le finalità indicate nel messaggio stesso. Qualora
> riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
> cortesemente di darcene notizia via e-mail e di procedere alla
> distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
> Conservare il messaggio stesso, divulgarlo anche in parte,
> distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
> diverse, costituisce comportamento contrario ai principi dettati dal
> D.Lgs. 196/2003.
>
> The information in this message and/or attachments, is intended solely
> for the attention and use of the named addressee(s) and may be
> confidential or proprietary in nature or covered by the provisions of
> privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
> Data Protection Code).Any use not in accord with its purpose, any
> disclosure, reproduction, copying, distribution, or either
> dissemination, either whole or partial, is strictly forbidden except
> previous formal approval of the named addressee(s). If you are not the
> intended recipient, please contact immediately the sender by
> telephone, fax or e-mail and delete the information in this message
> that has been received in error. The sender does not give any warranty
> or accept liability as the content, accuracy or completeness of sent
> messages and accepts no responsibility  for changes made after they
> were sent or for other risks which arise as a result of e-mail
> transmission, viruses, etc.
>
>
>
>
>
> --
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
---

Re: [Geotools-devel] SLD Stroke Dasharray Property

[Jody Garnett]

Yep.

I think we may map Label to several expressions, or perhaps it is a single
concatenate expression which is a variable argument function.

Actually if you want to follow that line of reasoning you could make an
function to evaluate
 a list of expressions into a double[] - and then the parser / encoder keep
an eye out for that function.

Have a look at how label is parsed in anycase - it is a similar problem.

--
Jody Garnett

On 6 July 2015 at 15:00, Nuno Oliveira 
wrote:

> Hi,
>
> > The principle is not exactly the same as linecap and linejoin are single
> values, while a dasharray is an array of values.
>
> You're right my bad ...
>
> > I believe that's why Jody was expecting a Expression[], one expression
> for each float/double value to be returned.
> > This is more in line with the existing API than assuming a single string
> that then needs to be tokenized
> > using the comma as a separator.
>
> I assumed that an SLD property should always be mapped to a single
> expression. So should I consider that a dash-array
> property could be mapped to several expressions ?
>
> Best regards,
>
> Nuno Oliveira
>
> Le dimanche 05 juillet 2015 à 09:38 +0100, Andrea Aime a écrit :
> > On Fri, Jul 3, 2015 at 8:51 PM, Nuno Oliveira
> >  wrote:
> > Thanks for your feedback.
> >
> > I'm a bit lost about his one 
> >
> > I follow the same principie of others methods in that class,
> > for example:
> >
> > public static String lineLinecap(LineSymbolizer
> > symbolizer) ...
> > public static String lineLinejoin(LineSymbolizer
> > symbolizer) ...
> >
> >
> > The principle is not exactly the same as linecap and linejoin are
> > single values,
> > while a dasharray is an array of values.
> > I believe that's why Jody was expecting a Expression[], one expression
> > for
> > each float/double value to be returned. This is more in line with the
> > existing
> > API than assuming a single string that then needs to be tokenized
> > using the comma
> > as a separator
> >
> >
> > Cheers
> > Andrea
> >
> >
> >
> >
> > --
> > ==
> > GeoServer Professional Services from the experts! Visit
> > http://goo.gl/it488V for more information.
> > ==
> >
> >
> >
> > Ing. Andrea Aime
> >
> > @geowolf
> > Technical Lead
> >
> >
> > GeoSolutions S.A.S.
> > Via Poggio alle Viti 1187
> > 55054  Massarosa (LU)
> > Italy
> > phone: +39 0584 962313
> > fax: +39 0584 1660272
> > mob: +39 339 8844549
> >
> >
> > http://www.geo-solutions.it
> > http://twitter.com/geosolutions_it
> >
> >
> > AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
> >
> > Le informazioni contenute in questo messaggio di posta elettronica e/o
> > nel/i file/s allegato/i sono da considerarsi strettamente riservate.
> > Il loro utilizzo è consentito esclusivamente al destinatario del
> > messaggio, per le finalità indicate nel messaggio stesso. Qualora
> > riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
> > cortesemente di darcene notizia via e-mail e di procedere alla
> > distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
> > Conservare il messaggio stesso, divulgarlo anche in parte,
> > distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
> > diverse, costituisce comportamento contrario ai principi dettati dal
> > D.Lgs. 196/2003.
> >
> >
> >
> > The information in this message and/or attachments, is intended solely
> > for the attention and use of the named addressee(s) and may be
> > confidential or proprietary in nature or covered by the provisions of
> > privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
> > Data Protection Code).Any use not in accord with its purpose, any
> > disclosure, reproduction, copying, distribution, or either
> > dissemination, either whole or partial, is strictly forbidden except
> > previous formal approval of the named addressee(s). If you are not the
> > intended recipient, please contact immediately the sender by
> > telephone, fax or e-mail and delete the information in this message
> > that has been received in error. The sender does not give any warranty
> > or accept liability as the content, accuracy or completeness of sent
> > messages and accepts no responsibility  for changes made after they
> > were sent or for other risks which arise as a result of e-mail
> > transmission, viruses, etc.
> >
> >
> >
> >
> > ---
>
>
>
>
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel