Hi,
Wanted to throw a little experience we had with names and how we solved them;
We have an upload capability with our application for users with specific roles
to upload a zipped shape file for inclusion with the catalog via ingestion to a
PostGIS database. Our initial use case when learning GeoServer was all WMS
calls. When we began to experiment with WFS returns via GML and GeoJSON, we
found the issue with the names. Because the potential exists for the data
returning via WFS and may be used for WFS-T updates, we had to ensure the names
were valid XML element names. We found out through trial and error that the
layer name had to be XML consistent while learning how to call WFS-T for
updates to previously uploaded shapes. Error messages returned indicated the
source of the problem. I suspect that many new geospatial developers find out
the naming requirements this way.
Our Solution:
We implemented a layer verification step for administrators to provide a layer
name, security roles, etc. before the layer is actually added to the GeoServer
catalog via REST calls. During the verification phase, the proposed name
provided by the administrator is checked for XML consistency as well as
uniqueness within the catalog. If the name is not valid for XML, we display
the appropriate error message. If the name is not unique, we append a 1, 2, 3
etc. to the end of the name ensuring the name is unique both as a test as well
as during the actual save call in cases of race condition upon verification.
I agree that fixing layer names is the responsibility of the administrator and
the application attempting to "help" by automatically renaming or hiding the
layers overall is a bad thing. It would not be very pleasant to the end user
when a layer they were expecting disappears from the dynamic catalog. By the
same token, the portions of GeoServer that are sensitive to the name
requirements already appear to provide proper error messages for an
administrator or end client application developer to make corrections.
Regarding the original error message and use case that Andrea reported, the
application has specific use cases that worked until GeoServer was updated in
an attempt to solve a problem that didn't even exist. The application
developers already know whether their use of GeoServer will utilize XML
generated output or require XML updates via WFS-T and generate the layer naming
convention based on their use. Enforcing a particular naming requirement is
the responsibility of the client/administering application, even if it is
GeoServer Web UI. In the case of the GeoServer UI, checks can be put in place
for the name when adding or updating a layer on the "Edit Layer" screen with a
warning message when a name is not applicable for particular uses cases such as
WFS. The layers listing screen can be updated to add a warning message next to
the layer name indicating when the name is not valid for WFS.
My .03...
Thanks,
Chris Snider
Senior Software Engineer
Intelligent Software Solutions, Inc.
[Description: Description: Description: cid:[email protected]]
From: Rahkonen Jukka (MML) [mailto:[email protected]]
Sent: Saturday, January 31, 2015 3:17 AM
To: Jody Garnett; Andrea Aime
Cc: Geoserver-devel
Subject: Re: [Geoserver-devel] Regression in 2.7.x, valid coverage names are
rejected because not valid xml names
Based on the 29 open tickets which deal with non-simple resource names we have
real issues with them. Could we at least try to emphasize in the documentation
and perhaps with some warning in the GUI that using such names calls for
troubles?
-Jukka Rahkonen-
________________________________
Jody Garnett wrote:
I am uncomfortable with the idea of silently disabling feature type layers - if
the user has turned on both WFS and WMS publication.
This proposal has drifted too far from my original goals. I will mark it
withdrawn and focus on fixing the style names in isolation.
--
Jody Garnett
On 30 January 2015 at 13:33, Jody Garnett
<[email protected]<mailto:[email protected]>> wrote:
So we are left with the question of how to notify admins for layers that are
disabled for a specific service.
As for the styles name change (damage is currently already done and is
affecting ability to upgrade) we can either allow the invalid characters (with
a warning) or watch them fail.
--
Jody
--
Jody Garnett
On 30 January 2015 at 13:05, Andrea Aime
<[email protected]<mailto:[email protected]>> wrote:
On Fri, Jan 30, 2015 at 7:29 PM, Jody Garnett
<[email protected]<mailto:[email protected]>> wrote:
I guess I see where the friction is coming from, you are focused on the
external name used by WMS and I am thinking of keeping our internal catalog
consistent. Usually we have kept the name as internal machine readable for
machine to machine communication, keeping the title and description for humans.
Let me break it to you: title and description are, in the field, pretty much
irrelevant, what counts is the name you publish in the services,
the one the clients will use to make the requests.
In my experience title and description are used by the clients that are
following the full protocol in order to discover the layers
and present a description to the user, that is, desktop clients, and those web
clients that allow you to dynamically mix in
layers from remote, provided at runtime, servers.
To those clients changing the layer name is irrelevant, because they are
discovering it every time, but they represent a very
small part of the actual traffic.
In most (all?) the small and big traffic sites I've seen the main traffic
driver is the custom web/mobile application that you setup
in order to expose whatever business service you are providing (rounting? green
areas management? wheather forecast?)
That thing knows the layer _names_, not titles and description, if you change
them while upgrading GeoServer the few
important web clients out there are broken, and you're not really providing
services anymore (that is, 99% of your traffic
is instantly gone).
I was just talking yesterday to some customers, their main concern was "can't I
just upgrade the GeoServer to a new version?".
My answer has been that we try to do our best to preserve backwards
compatibility... a change in the name of objects
that are exposed to the clients is exactly the opposite, marches straight in
the direction of maximum damage
To give you another small example, we have a customer that had published sample
URLs that did not have the &version
parameter, when they upgraded GeoServer some time ago, and WFS passed by
default from 1.1 to 2.0 we had a very bad week
with their customers complaining like crazy that the responses changed.
Eventually I've implememented a servlet
filter that forces 1.1 in case it's not specified... (yes, adding a
configuration to GeoServer to choose the default
version would have been better, but we were in damage control mode).
Long story short, an upgrade should always be transparent.
If you are that worried about the layer name is it worth breaking out a layer
field specifically to take control over what is seen on the WMS protocol? Yes
by extension you could have specific fields for WCS and WFS but I am not sure
those protocols are as sensitive to web map client restrictions?
They are used a lot do perform small extraction/download, we should not break
names there either.
As said above, an automatic name change during a installation upgrade is simply
a no-go, it's irresponsible and
will cost us a lot of users if we go that way.
I still go back to my previous idea, if a name is unsuitable for the a
particular protocol/version name restrictions, just
hide it to avoid breaking the protocol, but leave if for the protocols/versions
that do not mind.
It's easy, eliminate the damage of ill chosen names, and put the admin in a
position to amend whatever does
not otherwise damage them
Cheers
Andrea
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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<tel:%2B39%200584%20962313>
fax: +39 0584 1660272<tel:%2B39%200584%201660272>
mob: +39 339 8844549<tel:%2B39%20%C2%A0339%208844549>
http://www.geo-solutions.it<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.
-------------------------------------------------------
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
