Re: [Geoserver-users] GeoServer 2.22-M0 Milestone and foss4g workshop results

[Jody Garnett]

Thanks Jukka for the clarification.

I also noted that when writing the WMTS result some of the operation URLs
are incorrect which can cause problems if global web services are disabled
(for example).

Going to report the two issues here:
- https://osgeo-org.atlassian.net/browse/GEOS-10647 Welcome page links to
GetCapabilities do not follow the OGC standards
- https://osgeo-org.atlassian.net/browse/GEOS-10648 WMTS GetCapabilities
legend and template links incorrect

Jody

On Thu, Sep 8, 2022 at 12:16 AM Rahkonen Jukka <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Hi,
>
>
>
> About the non-standard GetCapabilities links, I think that there is
> nothing new in those, they have always been wrong. This is a list of all
> the links on the welcome page:
>
>
> http://localhost:8080/geoserver/ows?service=wms=1.3.0=GetCapabilities
>
>
> http://localhost:8080/geoserver/ows?service=wms=1.1.1=GetCapabilities
>
>
> http://localhost:8080/geoserver/gwc/service/wms?request=GetCapabilities=1.1.1=true
>
>
> http://localhost:8080/geoserver/gwc/service/wmts?services=WMTS=1.1.1=GetCapabilities
>
>
> http://localhost:8080/geoserver/ows?service=wfs=2.0.0=GetCapabilities
>
>
> http://localhost:8080/geoserver/ows?service=wfs=1.1.0=GetCapabilities
>
>
> http://localhost:8080/geoserver/ows?service=wfs=1.0.0=GetCapabilities
>
>
> http://localhost:8080/geoserver/ows?service=WCS=2.0.1=GetCapabilities
>
>
> http://localhost:8080/geoserver/ows?service=wcs=1.1.1=GetCapabilities
>
>
> http://localhost:8080/geoserver/ows?service=wcs=1.1.0=GetCapabilities
>
>
> http://localhost:8080/geoserver/ows?service=wcs=1.1=GetCapabilities
>
>
> http://localhost:8080/geoserver/ows?service=wcs=1.0.0=GetCapabilities
>
>
>
> In the OGS standards the keys are not case sensitive but the values are
> case sensitive, so the service name is correct only for WCS 2.0.1 and
> WMTS.  In the GWC links the WMS link does not have service at all, and WMTS
> link has a typo “services=WMTS”. Newest WFS 2.0 and WCS 2.0.1 standards
> refer to OGC Web Services Common Standard and therefore GetCapabilities
> should use  instead of 
>
>
>
> If standards were followed strictly all of the current links should return
> an error.  It is good that Geoserver is lenient but it would not hurt to
> have  conformant  links. BTW. there is one exception, with WCS 2.0.1
> Geoserver is strict:
>
> localhost:8080/geoserver/ows?service=wcs=2.0.1=GetCapabilities
> gives “Error in service name, expected value:
> WCS
>
>
>
> -Jukka Rahkonen-
>
>
>
>
>
> *Lähettäjä:* Jody Garnett 
> *Lähetetty:* keskiviikko 7. syyskuuta 2022 9.15
> *Vastaanottaja:* Rahkonen Jukka 
> *Kopio:* GeoServer Users 
> *Aihe:* Re: [Geoserver-users] GeoServer 2.22-M0 Milestone and foss4g
> workshop results
>
>
>
> Jukka:
>
>
>
> Thanks for the testing! some comments inline
>
>
>
> On Mon, Sep 5, 2022 at 1:04 PM Rahkonen Jukka <
> jukka.rahko...@maanmittauslaitos.fi> wrote:
>
> Hi,
>
>
>
> M0 starts without problems on Windows 10 with Eclipse Adoptium: 11.0.15
> (OpenJDK 64-Bit Server VM).
>
> The welcome page looks nice to me. A possibility to filter by workspace
> and layer name is certainly useful for those who use different
> configurations for workspaces.
>
>
>
> In speaking with people at foss4g almost nobody was aware this
> functionality existed. It also makes use of layergroup.
>
>
>
> I could easily add translation for layer titles and descriptions but it
> was not obvious to me how the translations should show in the UI when I
> change the language of the UI and what effect they should have on
> GetCapabities, if any.  I see now Finnish titles in the layer list also
> when I select English as language, and WMS GetCapabilities shows the
> Finnish translation at Title.
>
>
>
> I am not sure I understand? The service title and descriptions will be
> shown in the user interface. The layer title and descriptions are used in
> the generation of the getcapabilities document.
>
>
>
> But you did give me an idea; when a language is selected would could
> add AcceptLanguages= * to the URL to reflect what is shown on
> screen?
>
>
>
> The ne dataset is nice and helps with checking if own datasets appear on a
> correct place. One style for countries could include country names as
> labels.
>
>
>
> That is a good idea, I have a style somewhere that adjusts label based on
> scale, using an abbreviation when needed. I think we could also make the
> style use the i18n functionality to reflect the current language.
>
>
>
> Many of the links to GetCapabilities of the services do not follow the OGC
> standards. I will try to make a pull request to fix them.
>
>
>
> What do you mean? I do not think I changed  anything here, only inserting
> workspace / layer name as needed into the URL.
>
>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* Jody Garnett 
> *Lähetetty:* tiistai 30. elokuuta 2022 21.35
> *Vastaanottaja:* GeoServer Users 
> *Aihe:* [Geoserver-users] GeoServer 2.22-M0 Milestone and foss4g workshop
> results
>
>
>
> Jody 

Re: [Geoserver-users] proper use of sld to display wms layer

[Julien Robitaille]

Thanks for your input. I've looked at the DOTS_PER_INCH, but I dont think
it is still a valid parameter in openlayers (at least since the version 6).
But I found out that the arrow density seems to depend on
the devicePixelRatio of the window. As a matter of fact, if I increase
the devicePixelRatio of my browser (to a value similar to the one of my
phone) by zooming it in, I get the same arrow density as the layer
displayed on a smartphone.
So with that information I will be able to create two different sld styles,
one for higher devicePixelRatio (usually smartphones), and one for
lower devicePixelRatio (usually computers).
Thanks everyone for your help!
Julien

Le ven. 9 sept. 2022 à 10:26, Russ Hore  a écrit :

> I am no expert in OpenLayers but could the OpenLayers option;
>
> OpenLayers.DOTS_PER_INCH = 25.4 / 0.28;
>
> help? Can it force the DPI to be the same no matter what the Device DPI is.
>
>
> On 9 Sep 2022, at 14:39, Julien Robitaille  wrote:
>
> By resolution, do you mean the dpi resolution? Or maybe the "resolution"
> of my raster layer (size of georeferenced cells)? The best way to play with
> the concentration of arrows that I found was to play with
> the wms_scale_denominator. So I thought I could make two different sld
> styles, one for computers, and another one for smartphones, with different
> values of wms_scale_denominator. And depending on the screen size and/or
> resolution of screen of the user, one of the two styles would be applied to
> the layer.
> Thanks again,
> Julien
>
> Le jeu. 8 sept. 2022 à 18:16, Jody Garnett  a
> écrit :
>
>> Please remember to include the user list (so others can answer you) and
>> yeah sorry it does not support pictures.
>>
>> Where is the resolution of your raster determined?
>>
>> Jody
>>
>> On Thu, Sep 8, 2022 at 12:31 PM Julien Robitaille 
>> wrote:
>>
>>> hello,
>>> As a follow up, I would just need another specification.
>>> Here is the rendering when the dpi is set to 200:
>>>
>>> And here is the rendering when set to 60:
>>>
>>
>> As you can see, the resolution of the image didnt change (same number of
>>> arrows for the same zoom level). Only the size of the arrows have.
>>> Is it the expected result? What I am looking for is a way to decrease
>>> resolution for specific user cases.
>>> Thanks again!
>>> Julien
>>>
>>> Le jeu. 8 sept. 2022 à 12:22, Jody Garnett  a
>>> écrit :
>>>
 aside: Your messages are being held because of the attached images;
 here is my reply.

 The challenge faced here is not particular to geoserver - it is a
 design challenge on how you wish to adapt your map to different
 environments.

 You can supply GeoServer with the dpi of the display used  (have
 openlayers pass this information in as a format option) . GeoSerer will
 adjust the sizes appropriately. Much of the other information is available
 as env variables for use when styling.

 Reference:
 -
 https://docs.geoserver.org/latest/en/user/services/wms/vendor.html?highlight=dpi#format-options
 -

 https://docs.geoserver.org/latest/en/user/styling/sld/extensions/substitution.html#sld-variable-substitution


 On Thu, Sep 8, 2022 at 8:17 AM Julien Robitaille 
 wrote:

> Hello!
> I found out that the difference in size from one zoom level to another
> one comes from openlayers.
>
> But in any cases, what I would like to do is to increase the sizes of
> the arrows, so it is easier to see. The problem is that the display of
> those arrows depends a lot on whether the user uses a computer or a
> smartphone.
> Here is an example. The first picture is from my computer, and the
> second one is from my phone.
> As you can see, the resolution of the arrows is not the same, even at
> the approximate same zoom level.
>
> (images removed)
>

> As you can see, increasing the size of the arrows would make the app
> unreadable on the phone.
> Does anyone know how to address this problem? Is it something that can
> be fixed by geoserver, or is it more of an openlayers' problem?
>
> Thanks a lot for your help!
> Julien
>
> Le mar. 6 sept. 2022 à 10:08, Olivier Gagnon  a
> écrit :
>
>> Hi Julien (je suis aussi du Québec) !
>>
>> Have you tried using a fixed value for the Size attribute ?
>>
>> ex: 8
>>
>> As I can see in your sld, the size is modified using the Categorize
>> function.
>>
>> Hope this helps. Good Luck!
>>
>> Olivier
>>
>> Envoyé à partir d’Outlook 
>>
>> --
>> *De :* Julien Robitaille 
>> *Envoyé :* 6 septembre 2022 08:53
>> *À :* geoserver-users@lists.sourceforge.net <
>> geoserver-users@lists.sourceforge.net>
>> *Objet :* [Geoserver-users] proper use of sld to display wms layer
>>
>> Hello!
>> I have a raster layer that 

Re: [Geoserver-users] proper use of sld to display wms layer

[Russ Hore]

I am no expert in OpenLayers but could the OpenLayers option;

OpenLayers.DOTS_PER_INCH = 25.4 / 0.28;

help? Can it force the DPI to be the same no matter what the Device DPI is.


> On 9 Sep 2022, at 14:39, Julien Robitaille  wrote:
> 
> By resolution, do you mean the dpi resolution? Or maybe the "resolution" of 
> my raster layer (size of georeferenced cells)? The best way to play with the 
> concentration of arrows that I found was to play with the 
> wms_scale_denominator. So I thought I could make two different sld styles, 
> one for computers, and another one for smartphones, with different values of 
> wms_scale_denominator. And depending on the screen size and/or resolution of 
> screen of the user, one of the two styles would be applied to the layer.
> Thanks again,
> Julien
> 
> Le jeu. 8 sept. 2022 à 18:16, Jody Garnett  > a écrit :
> Please remember to include the user list (so others can answer you) and yeah 
> sorry it does not support pictures.
> 
> Where is the resolution of your raster determined? 
> 
> Jody
> 
> On Thu, Sep 8, 2022 at 12:31 PM Julien Robitaille  > wrote:
> hello,
> As a follow up, I would just need another specification. 
> Here is the rendering when the dpi is set to 200:
> 
> And here is the rendering when set to 60:
> 
> As you can see, the resolution of the image didnt change (same number of 
> arrows for the same zoom level). Only the size of the arrows have. 
> Is it the expected result? What I am looking for is a way to decrease 
> resolution for specific user cases. 
> Thanks again! 
> Julien
> 
> Le jeu. 8 sept. 2022 à 12:22, Jody Garnett  > a écrit :
> aside: Your messages are being held because of the attached images; here is 
> my reply.
> 
> The challenge faced here is not particular to geoserver - it is a design 
> challenge on how you wish to adapt your map to different environments.
> 
> You can supply GeoServer with the dpi of the display used  (have openlayers 
> pass this information in as a format option) . GeoSerer will adjust the sizes 
> appropriately. Much of the other information is available as env variables 
> for use when styling.
> 
> Reference:
> - 
> https://docs.geoserver.org/latest/en/user/services/wms/vendor.html?highlight=dpi#format-options
>  
> 
> - 
> https://docs.geoserver.org/latest/en/user/styling/sld/extensions/substitution.html#sld-variable-substitution
>  
> 
> 
> 
> On Thu, Sep 8, 2022 at 8:17 AM Julien Robitaille  > wrote:
> Hello! 
> I found out that the difference in size from one zoom level to another one 
> comes from openlayers.
> 
> But in any cases, what I would like to do is to increase the sizes of the 
> arrows, so it is easier to see. The problem is that the display of those 
> arrows depends a lot on whether the user uses a computer or a smartphone.
> Here is an example. The first picture is from my computer, and the second one 
> is from my phone. 
> As you can see, the resolution of the arrows is not the same, even at the 
> approximate same zoom level.
> 
> (images removed)
> 
> As you can see, increasing the size of the arrows would make the app 
> unreadable on the phone. 
> Does anyone know how to address this problem? Is it something that can be 
> fixed by geoserver, or is it more of an openlayers' problem? 
> 
> Thanks a lot for your help!
> Julien
> 
> Le mar. 6 sept. 2022 à 10:08, Olivier Gagnon  > a écrit :
> Hi Julien (je suis aussi du Québec) !
> 
> Have you tried using a fixed value for the Size attribute ? 
> 
> ex: 8
> 
> As I can see in your sld, the size is modified using the Categorize function.
> 
> Hope this helps. Good Luck!
> 
> Olivier
> 
> Envoyé à partir d’Outlook 
> 
> De : Julien Robitaille mailto:robitail...@ogsl.ca>>
> Envoyé : 6 septembre 2022 08:53
> À : geoserver-users@lists.sourceforge.net 
>  
>  >
> Objet : [Geoserver-users] proper use of sld to display wms layer
>  
> Hello! 
> I have a raster layer that displays surface currents. Everything works great, 
> but there are some details that I wish to get rid of but dont know how to. 
> Below, the two pictures show what the layer looks like at a different zoom 
> level. The first one is zoomed out compared to the second one. As you can 
> see, the arrows are smaller on the second one. I wish it wasnt like this. I'm 
> trying to make it so that the arrows stay the same size. 
> I've tried to play around with the wms_scale_denominator property in my sld, 
> but it doesnt seem to do the trick.
> 
> (images removed)
> 
> Here is my SLD:
> 
> 
> 

Re: [Geoserver-users] proper use of sld to display wms layer

[Julien Robitaille]

By resolution, do you mean the dpi resolution? Or maybe the "resolution" of
my raster layer (size of georeferenced cells)? The best way to play with
the concentration of arrows that I found was to play with
the wms_scale_denominator. So I thought I could make two different sld
styles, one for computers, and another one for smartphones, with different
values of wms_scale_denominator. And depending on the screen size and/or
resolution of screen of the user, one of the two styles would be applied to
the layer.
Thanks again,
Julien

Le jeu. 8 sept. 2022 à 18:16, Jody Garnett  a
écrit :

> Please remember to include the user list (so others can answer you) and
> yeah sorry it does not support pictures.
>
> Where is the resolution of your raster determined?
>
> Jody
>
> On Thu, Sep 8, 2022 at 12:31 PM Julien Robitaille 
> wrote:
>
>> hello,
>> As a follow up, I would just need another specification.
>> Here is the rendering when the dpi is set to 200:
>>
>> And here is the rendering when set to 60:
>>
>
> As you can see, the resolution of the image didnt change (same number of
>> arrows for the same zoom level). Only the size of the arrows have.
>> Is it the expected result? What I am looking for is a way to decrease
>> resolution for specific user cases.
>> Thanks again!
>> Julien
>>
>> Le jeu. 8 sept. 2022 à 12:22, Jody Garnett  a
>> écrit :
>>
>>> aside: Your messages are being held because of the attached images; here
>>> is my reply.
>>>
>>> The challenge faced here is not particular to geoserver - it is a design
>>> challenge on how you wish to adapt your map to different environments.
>>>
>>> You can supply GeoServer with the dpi of the display used  (have
>>> openlayers pass this information in as a format option) . GeoSerer will
>>> adjust the sizes appropriately. Much of the other information is available
>>> as env variables for use when styling.
>>>
>>> Reference:
>>> -
>>> https://docs.geoserver.org/latest/en/user/services/wms/vendor.html?highlight=dpi#format-options
>>> -
>>>
>>> https://docs.geoserver.org/latest/en/user/styling/sld/extensions/substitution.html#sld-variable-substitution
>>>
>>>
>>> On Thu, Sep 8, 2022 at 8:17 AM Julien Robitaille 
>>> wrote:
>>>
 Hello!
 I found out that the difference in size from one zoom level to another
 one comes from openlayers.

 But in any cases, what I would like to do is to increase the sizes of
 the arrows, so it is easier to see. The problem is that the display of
 those arrows depends a lot on whether the user uses a computer or a
 smartphone.
 Here is an example. The first picture is from my computer, and the
 second one is from my phone.
 As you can see, the resolution of the arrows is not the same, even at
 the approximate same zoom level.

 (images removed)

>>>
 As you can see, increasing the size of the arrows would make the app
 unreadable on the phone.
 Does anyone know how to address this problem? Is it something that can
 be fixed by geoserver, or is it more of an openlayers' problem?

 Thanks a lot for your help!
 Julien

 Le mar. 6 sept. 2022 à 10:08, Olivier Gagnon  a
 écrit :

> Hi Julien (je suis aussi du Québec) !
>
> Have you tried using a fixed value for the Size attribute ?
>
> ex: 8
>
> As I can see in your sld, the size is modified using the Categorize
> function.
>
> Hope this helps. Good Luck!
>
> Olivier
>
> Envoyé à partir d’Outlook 
>
> --
> *De :* Julien Robitaille 
> *Envoyé :* 6 septembre 2022 08:53
> *À :* geoserver-users@lists.sourceforge.net <
> geoserver-users@lists.sourceforge.net>
> *Objet :* [Geoserver-users] proper use of sld to display wms layer
>
> Hello!
> I have a raster layer that displays surface currents. Everything works
> great, but there are some details that I wish to get rid of but dont know
> how to.
> Below, the two pictures show what the layer looks like at a different
> zoom level. The first one is zoomed out compared to the second one. As
> you can see, the arrows are smaller on the second one. I wish it wasnt 
> like
> this. I'm trying to make it so that the arrows stay the same size.
> I've tried to play around with the wms_scale_denominator property in
> my sld, but it doesnt seem to do the trick.
>
> (images removed)
>
> Here is my SLD:
>
> 
> xsi:schemaLocation="http://www.opengis.net/sld
> StyledLayerDescriptor.xsd"
>xmlns="http://www.opengis.net/sld;
>xmlns:ogc="http://www.opengis.net/ogc;
>xmlns:xlink="http://www.w3.org/1999/xlink;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
>   
>currents
>
>  currents
>  
>
>  
>
>  data
>  

Re: [Geoserver-users] Smart Data Loader and Feature Templating plugins fail to work with Array Type (PostgreSQL)

[Henning Lorenz]

Dear Nuno,

Thanks for the quick reply. However, for the Feature Templating plugin, 
it contradicts the documentation where Array Type support for json 
output is explicitly mentioned: 
https://docs.geoserver.org/stable/en/user/community/features-templating/directives.html#array-based-properties-json-based-templates-only


Is the documentation wrong and needs to be updated?

Best wishes,

Henning


On 2022-09-09 11:42, Nuno Oliveira wrote:

Dear Henning,
those modules do not support array column types, this would be a nice 
feature to have.


A pull request contributing it would be very welcomed, you may also 
want to check the GeoServer Support  
in case you want to fund it.


Kind regards,
Nuno Oliveira

On Fri, Sep 9, 2022 at 10:13 AM Henning Lorenz 
 wrote:


geoserver 2.21, app schema/smart data loader/ogc api/feature
templating plugins (Tomcat 9 on Ubuntu 22.04; openjdk 11.0.16)

Hello,

I appreciate any help on the following two (related?) problems
(further explained below):

 1. The "Smart Data Loader" plugin fails in case Array Type is
present in one of the tables (error unknown data type)
 2. The "Feature Templating" plugin does not handle data from
columns with Array Type correctly ("[Ljava.lang.String;@..."
)

Of particular importance to me is to solve problem 2, as this
directly affects geoserver output.

Many thanks in advance,

Henning

-

Problem 1:

  * I create two tables, one without and one without a column of
Array Type (called here "noarray_table" and "array_table";
only for explanation instead of my more complex setup):

CREATE TABLE test.noarray_table (
    id SERIAL PRIMARY KEY,
    geometry geometry(point, 4326),
    attribute1 varchar,
    attribute2 varchar
);

CREATE TABLE test.array_table (
    id SERIAL PRIMARY KEY,
    geometry geometry(point, 4326),
    attribute1 varchar,
    attribute2 varchar[]
);

  * After adding some data, I create a PostGIS data store for
database that contains the tables.
  * When this is done, I add a new data store and select "Smart
Data Loader".
  o When I select the noarray_table as root entity, I get the
expected preview and can add the data store.
  o However, when I select the array_table, I get an error
message over the entire page. As far as I can tell, the
critical line is "Caused by: java.lang.RuntimeException:
Attribute type '_varchar' is unknown.". _varchar is the
same as varchar[] as far as I can tell.

Is this a bug or does Smart Data Loader not support Array Types
("missing feature")?


Problem 2:

The Feature Templating plugin explicitly supports Array Types
(see

https://docs.geoserver.org/stable/en/user/community/features-templating/directives.html#array-based-properties-json-based-templates-only)

  * With the Smart Data Loader, I create an app schema mapping and
schema of tables without Array Type
  * I configure feature templating and I get valid output.
  * However, one of the columns should actually be of array type.
Thus, I replace this varchar-column by a varchar[]-column,
including type casting of the content.
  o According to the documentation, I expect that the Array
Type of the column is recognised by the plugin and the
data are expanded accordingly.
  o However, I see "[Ljava.lang.String;@..."
 instead of data.
According to what I could find out, this indicates the
presence of array data where no array data are expected.

This leaves two options:

A) It is not sufficient to just change the Data Type in the
database, something in the configuration has to be changed as well
(App Schema mapping file, schema - although Array Type is not
supported for XML according to the documentation, which would
suggest that this is not the case).

B) The Feature Templating plugin doesn't work as expected, i.e.
it's a bug.










När du har kontakt med oss på Uppsala universitet med e-post så
innebär det att vi behandlar dina personuppgifter. För att läsa
mer om hur vi gör det kan du läsa här:
http://www.uu.se/om-uu/dataskydd-personuppgifter/

E-mailing Uppsala University means that we will process your
personal data. For more information on how this is performed,
please read here: http://www.uu.se/en/about-uu/data-protection-policy
___
Geoserver-users mailing list

Please make sure you read the following 

Re: [Geoserver-users] Smart Data Loader and Feature Templating plugins fail to work with Array Type (PostgreSQL)

[Nuno Oliveira]

Dear Henning,
those modules do not support array column types, this would be a nice
feature to have.

A pull request contributing it would be very welcomed, you may also want to
check the GeoServer Support  in case you
want to fund it.

Kind regards,
Nuno Oliveira

On Fri, Sep 9, 2022 at 10:13 AM Henning Lorenz 
wrote:

> geoserver 2.21, app schema/smart data loader/ogc api/feature templating
> plugins (Tomcat 9 on Ubuntu 22.04; openjdk 11.0.16)
>
> Hello,
>
> I appreciate any help on the following two (related?) problems (further
> explained below):
>
>1. The "Smart Data Loader" plugin fails in case Array Type is present
>in one of the tables (error unknown data type)
>2. The "Feature Templating" plugin does not handle data from columns
>with Array Type correctly ("[Ljava.lang.String;@..."
><[Ljava.lang.String;@...>)
>
> Of particular importance to me is to solve problem 2, as this directly
> affects geoserver output.
>
> Many thanks in advance,
>
> Henning
>
> -
>
> Problem 1:
>
>- I create two tables, one without and one without a column of Array
>Type (called here "noarray_table" and "array_table"; only for explanation
>instead of my more complex setup):
>
> CREATE TABLE test.noarray_table (
> id SERIAL PRIMARY KEY,
> geometry geometry(point, 4326),
> attribute1 varchar,
> attribute2 varchar
> );
>
> CREATE TABLE test.array_table (
> id SERIAL PRIMARY KEY,
> geometry geometry(point, 4326),
> attribute1 varchar,
> attribute2 varchar[]
> );
>
>
>- After adding some data, I create a PostGIS data store for database
>that contains the tables.
>- When this is done, I add a new data store and select "Smart Data
>Loader".
>   - When I select the noarray_table as root entity, I get the
>   expected preview and can add the data store.
>   - However, when I select the array_table, I get an error message
>   over the entire page. As far as I can tell, the critical line is "Caused
>   by: java.lang.RuntimeException: Attribute type '_varchar' is unknown.".
>   _varchar is the same as varchar[] as far as I can tell.
>
> Is this a bug or does Smart Data Loader not support Array Types ("missing
> feature")?
>
>
> Problem 2:
>
> The Feature Templating plugin explicitly supports Array Types
> (see
> https://docs.geoserver.org/stable/en/user/community/features-templating/directives.html#array-based-properties-json-based-templates-only
> )
>
>- With the Smart Data Loader, I create an app schema mapping and
>schema of tables without Array Type
>- I configure feature templating and I get valid output.
>- However, one of the columns should actually be of array type. Thus,
>I replace this varchar-column by a varchar[]-column, including type casting
>of the content.
>   - According to the documentation, I expect that the Array Type of
>   the column is recognised by the plugin and the data are expanded
>   accordingly.
>   - However, I see "[Ljava.lang.String;@..." <[Ljava.lang.String;@...>
>   instead of data. According to what I could find out, this indicates the
>   presence of array data where no array data are expected.
>
> This leaves two options:
>
> A) It is not sufficient to just change the Data Type in the database,
> something in the configuration has to be changed as well (App Schema
> mapping file, schema - although Array Type is not supported for XML
> according to the documentation, which would suggest that this is not the
> case).
>
> B) The Feature Templating plugin doesn't work as expected, i.e. it's a bug.
>
>
>
>
>
>
>
>
>
>
> När du har kontakt med oss på Uppsala universitet med e-post så innebär
> det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör
> det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/
>
> E-mailing Uppsala University means that we will process your personal
> data. For more information on how this is performed, please read here:
> http://www.uu.se/en/about-uu/data-protection-policy
> ___
> Geoserver-users mailing list
>
> Please make sure you read the following two resources before posting to
> this list:
> - Earning your support instead of buying it, but Ian Turton:
> http://www.ianturton.com/talks/foss4g.html#/
> - The GeoServer user list posting guidelines:
> http://geoserver.org/comm/userlist-guidelines.html
>
> If you want to request a feature or an improvement, also see this:
> https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
>
>
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>


-- 

Regards,

Nuno Oliveira

==
GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Technical Lead / 

[Geoserver-users] Smart Data Loader and Feature Templating plugins fail to work with Array Type (PostgreSQL)

[Henning Lorenz]

geoserver 2.21, app schema/smart data loader/ogc api/feature templating plugins 
(Tomcat 9 on Ubuntu 22.04; openjdk 11.0.16)

Hello,

I appreciate any help on the following two (related?) problems (further 
explained below):

 1.  The "Smart Data Loader" plugin fails in case Array Type is present in one 
of the tables (error unknown data type)
 2.  The "Feature Templating" plugin does not handle data from columns with Array Type 
correctly ("[Ljava.lang.String;@...")

Of particular importance to me is to solve problem 2, as this directly affects 
geoserver output.

Many thanks in advance,

Henning

-

Problem 1:

 *   I create two tables, one without and one without a column of Array Type (called here 
"noarray_table" and "array_table"; only for explanation instead of my more 
complex setup):

CREATE TABLE test.noarray_table (
   id SERIAL PRIMARY KEY,
   geometry geometry(point, 4326),
   attribute1 varchar,
   attribute2 varchar
);

CREATE TABLE test.array_table (
   id SERIAL PRIMARY KEY,
   geometry geometry(point, 4326),
   attribute1 varchar,
   attribute2 varchar[]
);

 *   After adding some data, I create a PostGIS data store for database that 
contains the tables.
 *   When this is done, I add a new data store and select "Smart Data Loader".
*   When I select the noarray_table as root entity, I get the expected 
preview and can add the data store.
*   However, when I select the array_table, I get an error message over the entire 
page. As far as I can tell, the critical line is "Caused by: 
java.lang.RuntimeException: Attribute type '_varchar' is unknown.". _varchar is the 
same as varchar[] as far as I can tell.

Is this a bug or does Smart Data Loader not support Array Types ("missing 
feature")?


Problem 2:

The Feature Templating plugin explicitly supports Array Types
(see 
https://docs.geoserver.org/stable/en/user/community/features-templating/directives.html#array-based-properties-json-based-templates-only)

 *   With the Smart Data Loader, I create an app schema mapping and schema of 
tables without Array Type
 *   I configure feature templating and I get valid output.
 *   However, one of the columns should actually be of array type. Thus, I 
replace this varchar-column by a varchar[]-column, including type casting of 
the content.
*   According to the documentation, I expect that the Array Type of the 
column is recognised by the plugin and the data are expanded accordingly.
*   However, I see 
"[Ljava.lang.String;@..." instead of data. 
According to what I could find out, this indicates the presence of array data where no array 
data are expected.

This leaves two options:

A) It is not sufficient to just change the Data Type in the database, something 
in the configuration has to be changed as well (App Schema mapping file, schema 
- although Array Type is not supported for XML according to the documentation, 
which would suggest that this is not the case).

B) The Feature Templating plugin doesn't work as expected, i.e. it's a bug.









När du har kontakt med oss på Uppsala universitet med e-post så innebär det att 
vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du 
läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/

E-mailing Uppsala University means that we will process your personal data. For 
more information on how this is performed, please read here: 
http://www.uu.se/en/about-uu/data-protection-policy
___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Connecting Jetty to Postgis using JNDI

[Micho García]

Hi Simone,

thanks. I am investigating the issue
https://osgeo-org.atlassian.net/browse/GEOS-10554 We have a similar case in
Satagro and we will need that Geoserver were able to remove the table of
the imagemosaic when we execute a DELETE operation to the datastore using
the purge method. This is why I am configuring Jetty with JNDI, only for
testing purposes. I think I could start Geoserver with Tomcat to develop,
Tomcat is less magical to me, but following the doc it looked like it was
easy to configure the Jetty with the JNDI but I haven't been able yet.

Thanks again for your help.

El jue, 8 sept 2022 a las 9:54, Simone Giannecchini (<
simone.giannecch...@geosolutionsgroup.com>) escribió:

> Micho,
> side note, if you are using the Jetty we ship with GeoServer, please don't.
> We ship that for prototyping and testing purposes, in production I would
> recommend having a full fledged installation of either Tomcat or Jetty or
> whatever application server you are confident with.
>
> Regards,
> Simone Giannecchini
> ==
> Professional Support for GeoNode, GeoServer and MapStore from the experts!
> Visit https://www.geosolutionsgroup.com/enterprise-support-services for
> more information.
> ==
> Ing. Simone Giannecchini
> @simogeo
> Founder/Director GeoSolutions Italy
> President GeoSolutions USA
>
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob:   +39  333 8128928
> US: +1 (845) 547-7905
>
> http://www.geosolutionsgroup.com
> http://twitter.com/geosolutions_it
>
> ---
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail.
>
>
> On Wed, Sep 7, 2022 at 4:47 PM Micho García 
> wrote:
>
>> Hi everybody,
>>
>> I'm Micho from geomatico.es and I'm having some problems connecting
>> geoserver's Jetty with Postgis using JNDI.
>>
>> I've read the documentation and I've configured a settings.xml with my
>> JNDI configuration (attached). I need to understand why geoserver is trying
>> to delete my whole indexes' database, but when I tried to publish an
>> imagemosaic I receive this error:
>>
>> 07 Sep 15:13:59 ERROR [gce.imagemosaic] - Unable to obtain connection:
>> Cannot create JDBC driver of class 'org.postgresql.Driver' for connect URL
>> 'jdbc:postgres://172.20.0.11:5432/satagro_indexes'
>> java.lang.RuntimeException: Unable to obtain connection: Cannot create
>> JDBC driver of class 'org.postgresql.Driver' for connect URL
>> 'jdbc:postgres://172.20.0.11:5432/satagro_indexes'
>>
>> I was investigating and I am almost sure that the Jetty is unable to get
>> the Driver but my problem is that I don't know where I should place
>> the postgresql-42.5.0.jar. I've placed into the $JETTY_HOME (in my case
>> /home/michogarcia/geomati.co/SATAGRO/dev/geoserver/src/release/jetty/)in
>> the $JETTY_HOME/resources and in several more places, but always with the
>> same result.
>>
>> Where I should place the .jar to be used by Jetty?.
>>
>> Thanks a lot.
>>
>> Best.
>>
>> settings.xml:
>>
>> 
>> > http://jetty.mortbay.org/configure.dtd;>
>> 
>> 
>> java:comp/env/jdbc/postgres
>> 
>> 
>> org.postgresql.Driver
>> jdbc:postgres://172.20.0.11:5432/satagro
>> 
>> satagro
>> 
>> 200
>> 8
>> 0
>> 1
>> 6
>> 3
>> 20
>> true
>> 100
>> true
>> SELECT SYSDATE FROM DUAL
>> true
>> 
>> 
>> 
>> 
>> java:comp/env/jdbc/indexes
>> 
>> 
>> org.postgresql.Driver
>> jdbc:postgres://
>> 172.20.0.11:5432/satagro_indexes
>> satagro
>> 
>> 200
>> 8
>> 0
>> 1
>> 6
>> 3
>> 20
>> true
>> 100
>> true
>> SELECT SYSDATE FROM DUAL
>> true
>> 
>> 
>> 
>> 
>>
>> --
>> Micho Garcia
>> geomatico.es
>>
>> *Política de Protección de Datos de Carácter Personal **Responsable:
>> GEOMATICO, S. COOP. GALEGA **CIF:  F-27875327 **Teléfono de contacto:
>> 623 066 080 **Correo electrónico:  i...@geomatico.es
>>  **Dirección postal: C/ Pi y Margall, 60, entlo.
>> ofic-2,  6202, Vigo, Pontevedra. **Los datos de carácter personal
>> contenidos en el 

Re: [Geoserver-users] Connecting Jetty to Postgis using JNDI

[Micho García]

Thanks Humphries. In the $JETTY_BASE, I didn't have the lib folder. I
created it and placed the jar inside but it didn't work. I will try again
but creating the jdbc folder too.

Thanks again.

El jue, 8 sept 2022 a las 1:41, Humphries, Graham (<
graham.humphr...@stategrowth.tas.gov.au>) escribió:

> According to some documentation I found (
> https://help.percussion.com/rhythmyx/implementation/jetty/jetty-file-structure.html)
> you should place database drivers here: jetty/base/lib/jdbc
>
>
>
> *From:* Micho García 
> *Sent:* Wednesday, 7 September 2022 11:38 PM
> *To:* GeoServer Mailing List List 
> *Subject:* [Geoserver-users] Connecting Jetty to Postgis using JNDI
>
>
>
> Hi everybody,
>
>
> I'm Micho from geomatico.es
> 
> and I'm having some problems connecting geoserver's Jetty with Postgis
> using JNDI.
>
>
> I've read the documentation and I've configured a settings.xml with my
> JNDI configuration (attached). I need to understand why geoserver is trying
> to delete my whole indexes' database, but when I tried to publish an
> imagemosaic I receive this error:
>
>
> 07 Sep 15:13:59 ERROR [gce.imagemosaic] - Unable to obtain connection:
> Cannot create JDBC driver of class 'org.postgresql.Driver' for connect URL
> 'jdbc:postgres://172.20.0.11:5432/satagro_indexes
> 
> '
> java.lang.RuntimeException: Unable to obtain connection: Cannot create
> JDBC driver of class 'org.postgresql.Driver' for connect URL
> 'jdbc:postgres://172.20.0.11:5432/satagro_indexes
> 
> '
>
> I was investigating and I am almost sure that the Jetty is unable to get
> the Driver but my problem is that I don't know where I should place
> the postgresql-42.5.0.jar. I've placed into the $JETTY_HOME (in my case
> /home/michogarcia/geomati.co/SATAGRO/dev/geoserver/src/release/jetty/)in
> 
> the $JETTY_HOME/resources and in several more places, but always with the
> same result.
>
>
> Where I should place the .jar to be used by Jetty?.
>
>
> Thanks a lot.
>
>
> Best.
>
>
>
> settings.xml:
>
>
>
> 
>  http://jetty.mortbay.org/configure.dtd
> 
> ">
> 
> 
> java:comp/env/jdbc/postgres
> 
> 
> org.postgresql.Driver
> jdbc:postgres://172.20.0.11:5432/satagro
> 
> 
> satagro
> 
> 200
> 8
> 0
> 1
> 6
> 3
> 20
> true
> 100
> true
>