Re: [Geoserver-users] OpenLayers with App-Schemas

[Ryan Clark]

Ben -

We got things to work by adjusting the Host header on the proxy server (nginx 
in this case), but before doing that we were seeing 127.0.0.1 addresses in the 
GetCapabilities and OpenLayers previews even though we had set the Geoserver 
proxy base url. We're using 2.3, so I'm curious why we seemed to be having the 
same issue that was solved at 2.1.x in that bug report you mentioned?

Just for the record, here's the nginx config snippet that we're using now (that 
works). Previously we weren't setting the Host header:

# By default, traffic is sent to Tomcat
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $http_host;
}

Thanks!
Ryan



____

Ryan Clark
Arizona Geological Survey
ryan.cl...@azgs.az.gov<mailto:ryan.cl...@azgs.az.gov>
(520) 302-4871
facebook.com/ModernGeologist<https://www.facebook.com/ModernGeologist>
@worbly<https://twitter.com/worbly>









On Sep 5, 2013, at 9:50 AM, "christy@azgs" 
mailto:christy.caud...@azgs.az.gov>>
 wrote:

Okay, so you can see that the OnlineResource in the GetCapabilities still
references 127.0.0.1

http://data.usgin.org/azgs_bedrock_geology/gsmlp/wms?service=WMS&version=1.3.0&request=GetCapabilities

And attached is a screen shot that the Proxy has been set, but is being
ignored:
<http://osgeo-org.1560.x6.nabble.com/file/n5076290/Proxy.jpg>




--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/OpenLayers-with-App-Schemas-tp5075263p5076290.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Virtual Services and Duplication of FeatureTypes

[Ryan Clark]

Hi!

We have a set of WFS services sourced from ArcGIS server and we're trying to 
replicate the functionality on Geoserver. The fundamental problem that I seem 
to be running up against is that:

- In ArcGIS Server, we provide multiple service endpoints, each of which 
provide the same WFS featuretype, but distinguished from each other because the 
source data comes from different state organizations. For example:

http://services.azgs.az.gov/ArcGIS/services/aasggeothermal/AZWellHeaders/MapServer/WFSServer?request=GetCapabilities&service=WFS

http://services.azgs.az.gov/ArcGIS/rest/services/aasggeothermal/CAWellHeaders/MapServer/WFSServer?request=GetCapabilities&service=WFS

http://services.azgs.az.gov/ArcGIS/rest/services/aasggeothermal/HIWellheaders/MapServer/WFSServer?request=GetCapabilities&service=WFS

- We also have, for example, a set of featuretypes for aqueous chemistry 
measurements. However we provide different service endpoints for measurements 
from hot springs vs. those from wells that have been drilled.

http://services.azgs.az.gov/ArcGIS/rest/services/aasggeothermal/AZaqSpringChemistry/MapServer/WFSServer?request=GetCapabilities&service=WFS

http://services.azgs.az.gov/ArcGIS/rest/services/aasggeothermal/AZaqWellChemistry/MapServer/WFSServer?request=GetCapabilities&service=WFS

- The featuretypes are backed by schema documents that we've written to 
validate the services, and thus the namespace URIs need to be consistent across 
the featuretypes.

In Geoserver, I understand that fundamentally you're providing one WFS service, 
and that puts some restriction on my being able to provide multiple layers 
based on a single featuretype. I can't seem to alleviate the problem through 
the use of the new Virtual Services, but thought I would check in to see if 
there might be something I'm overlooking, or if perhaps the app-schema 
extension might offer a mechanism to accomplish this?

Thank you!


Ryan Clark
ryan.cl...@azgs.az.gov
(520) 302-4871






--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Multi-part features lack "XML" CRS definition, flipped in ArcGIS

[Ryan Clark]

Using Geoserver 2.1.2, I ran into a silly situation when looking at WFS 
data in ArcGIS. /SOME/ of the polygons in the dataset have their 
coordinate axes reversed, while others don't. It's only a problem with 
GML3, it is WGS84 data, yadda yadda yadda.


I managed to track down the difference in this case: The table is 
identified by PostGIS and Geoserver as MULTIPOLYGON, although 
geometrytype(shape) returns POLYGON for some features and MULTIPOLYGON 
for others. Polygons that have multiple parts are exclusively drawn in 
ArcGIS with reversed axes, while single-part polygons plot in the right 
place.


If you look at a WFS response from Geoserver containing one poly and one 
multi-part poly, and look at the shape attributes. Both are 
 and that element has a defined srsName attribute 
using the URN scheme. However, for single-part features, the 
 is also given an srsName, this time giving the CRS 
definition by reference (http://www.opengis.net/...). Multi-part 
polygons don't have this extra srsName attribute on each , 
and then the features end up reversed in ArcGIS.


Here's a WFS Query to look at it:
http://services.azgs.az.gov/geoserver/ows?outputFormat=GML3&request=GetFeature&service=WFS&version=1.1.0&typename=gsmlp:GeologicUnitView&filter=%3CFilter%20xmlns=%22http://www.opengis.net/ogc%22%3E%3COr%3E%3CPropertyIsEqualTo%3E%3CPropertyName%3Egsmlp:objectid%3C/PropertyName%3E%3CLiteral%3E12230%3C/Literal%3E%3C/PropertyIsEqualTo%3E%3CPropertyIsEqualTo%3E%3CPropertyName%3Egsmlp:objectid%3C/PropertyName%3E%3CLiteral%3E7321%3C/Literal%3E%3C/PropertyIsEqualTo%3E%3C/Or%3E%3C/Filter%3E 



I've read up on all the documentation I can find about 
Geoserver/Geotools and CRS definitions, and I'm aware of the OGC 
coordinate snafus. Putting aside anything that ArcGIS might be doing 
wrong, three questions about Geoserver's behavior:


1. Why do single-part features get an extra srsName defined for them
   that multi-part features don't seem to get?
2. Even when the "XML" CRS definition is present (single-part
   polygons), the coordinates are presented as y/x -- is that how it
   should be? It seems backwards according to
   http://docs.geoserver.org/stable/en/user/webadmin/services/WFS.html#gml
3. On the WFS configuration page there are options to set the SRS Style
   for GML2 and GML3. I've played around with them, but I haven't seen
   any changes in the WFS GetCapabilities or GetFeature responses. What
   do these configurations do? I found an almost year-old post by
   Justin Deoliveira pointing out the issue (
   
http://osgeo-org.1803224.n2.nabble.com/Problem-with-WFS-GML-SRS-Style-tt6107591.html#a6107595),
   but I couldn't find an issue about it on JIRA.

Thank you,
Ryan

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] ArcSDE/PostGIS tables: An exception occurred while parsing WKB data

[Ryan Clark]

WKBAttributeIO.java:82)
at 
org.geotools.data.postgis.WKBAttributeIO.read(WKBAttributeIO.java:110)
at 
org.geotools.data.postgis.PostGISDialect.decodeGeometryValue(PostGISDialect.java:157)

at org.geotools.jdbc.JDBCFeatureReader.next(JDBCFeatureReader.java:321)
... 84 more
Caused by: com.vividsolutions.jts.io.ParseException: Unknown WKB type 93
at com.vividsolutions.jts.io.WKBReader.readGeometry(WKBReader.java:186)
at com.vividsolutions.jts.io.WKBReader.read(WKBReader.java:140)
at 
org.geotools.data.postgis.WKBAttributeIO.wkb2Geometry(WKBAttributeIO.java:80)

... 87 more

On 11/24/2011 02:25 AM, Andrea Aime wrote:
On Thu, Nov 24, 2011 at 12:45 AM, Ryan Clark <mailto:ryan.cl...@azgs.az.gov>> wrote:


I'm working on a database that has been generated as an ArcSDE
database on top of PostgreSQL and PostGIS. The database was built
from a PostGIS template and the featureclasses in the database use
the PostGIS geometry type.

On the database end, everything seems to be working fine. Queries like
/SELECT ST_asText(shape) as WKT, geometrytype(shape) as TYPE from
sde.azwellheaders
/... work just fine. The public.geometry_columns table is
populated correctly, including records for the shape fields from
all the featureclasses. I did notice that the
public.geometry_columns.type field just says "GEOMETRY", instead
giving a specific geometry type, but I think that's valid, right?


It is.


I tried building layers in Geoserver from a few of these
featureclasses. The UI correctly detects the SRID and can
correctly compute the bounds from the data. However, once the
layer is published and I look at the Layer Preview, click on GML
for my new layer, I get the following WFS response:

error:Translator error Translator error Error reading Features
org.geotools.data.DataSourceException: An exception occurred while
parsing WKB data An exception occurred while parsing WKB data
Unknown WKB type 93



Haven't seen this one before, but it may be that the geometry is using 
some extended type that is not supported
by JTS, and thus by GeoServer. For example, it would fail if the 
geometries were arcs (as opposed to be made

of straight segments).

Cheers
Andrea

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

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313

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

---
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] ArcSDE/PostGIS tables: An exception occurred while parsing WKB data

[Ryan Clark]

I'm working on a database that has been generated as an ArcSDE database 
on top of PostgreSQL and PostGIS. The database was built from a PostGIS 
template and the featureclasses in the database use the PostGIS geometry 
type.


On the database end, everything seems to be working fine. Queries like
/SELECT ST_asText(shape) as WKT, geometrytype(shape) as TYPE from 
sde.azwellheaders
/... work just fine. The public.geometry_columns table is populated 
correctly, including records for the shape fields from all the 
featureclasses. I did notice that the public.geometry_columns.type field 
just says "GEOMETRY", instead giving a specific geometry type, but I 
think that's valid, right?


I tried building layers in Geoserver from a few of these featureclasses. 
The UI correctly detects the SRID and can correctly compute the bounds 
from the data. However, once the layer is published and I look at the 
Layer Preview, click on GML for my new layer, I get the following WFS 
response:


error:Translator error Translator error Error reading Features 
org.geotools.data.DataSourceException: An exception occurred while 
parsing WKB data An exception occurred while parsing WKB data Unknown 
WKB type 93



I'm using Geoserver 2.1.2 and PostgreSQL 8.3.
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] CORS support for Geoserver?

[Ryan Clark]

Hello --

I'm curious if there is any inclination to provide cross-origin resource 
sharing support in Geoserver itself? It is pretty simple to configure 
Apache to handle CORS: http://enable-cors.org/#how-apache, and this 
servlet filter should do the trick in Tomcat: 
http://software.dzhuvinov.com/cors-filter-configuration.html. Something 
like that servlet filter working out-of-the-box with Geoserver seems 
like it would be a good idea, as most modern browsers support/require 
CORS. I would be a happier fellow if my OpenLayers applications could 
get away from OpenLayers.ProxyHost!

Thanks,
Ryan




--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] net.sf.saxon.TransformerFactoryImpl not found

[Ryan Clark]

Solved: I found a line in the second webapp's initialization class that said:
System.setProperty("javax.xml.transform.TransformerFactory", 
"net.sf.saxon.TransformerFactoryImpl");

Looks like someone thought that setProperty wouldn't operate on the entire 
Tomcat system...

Thanks,
Ryan



On Mar 12, 2011, at 10:21 AM, Andrea Aime wrote:

> On Sat, Mar 12, 2011 at 2:33 AM, Ryan Clark  wrote:
>> This is an old posting, but I've run into exactly this problem, and I can
>> identify that installing a specific app in the same Tomcat instance causes
>> Geoserver to have this problem. Unfortunately, I have to figure out how to
>> make the two apps work together. Can you provide any more insight into what
>> common libraries might be the guilty ones?
> 
> Not sure... GeoServer does not depend on use Saxon at all as far as I know.
> 
> Cheers
> Andrea
> 
> -- 
> ---
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
> 
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> 
> phone: +39 0584 962313
> fax:  +39 0584 962313
> mob:+39 333 8128928
> 
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
> 
> ---

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] net.sf.saxon.TransformerFactoryImpl not found

[Ryan Clark]

This is an old posting, but I've run into exactly this problem, and I can
identify that installing a specific app in the same Tomcat instance causes
Geoserver to have this problem. Unfortunately, I have to figure out how to
make the two apps work together. Can you provide any more insight into what
common libraries might be the guilty ones?

Thank you,
Ryan



--
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/net-sf-saxon-TransformerFactoryImpl-not-found-tp6120222p6163498.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Problems with web interface: click and nothing happens

[Ryan Clark]

I have two different Amazon VMs that are running Geoserver 2.0.2. One has been 
sitting there for a while without my having to pay much attention to it (Ubuntu 
server 9.04), another is a brand new build (Ubuntu server 10.10). I'm having 
some kind of interface trouble, where clicking some links works, and others 
don't.

For example, on my new build, I was able to add a Workspace, then I added a 
Store, entered the PostGIS connection information, clicked save and nothing 
happened. I checked the link for the Store, and it had created my Store, so 
okay... Then I try to publish a layer, and it lists the tables available in my 
store, but clicking the publish link does nothing at all. So it seems like it 
is some kind of problem related to publishing the table? Does this sound like a 
data-dependant issue, or some interface problem?

Any suggestions?

Thanks,
Ryan



--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] app-schema: 2 namespaces in one : how to?

[Ryan Clark]

Hi there!

I ran into exactly this problem myself. You need to create another folder in
your workspaces directory for the other namespace.

Here's some more information:
http://old.nabble.com/Re:-App-schema-and-GeoSciML-3.0:-cgu:CGI_Term-p2934174
5.html

http://docs.geoserver.org/stable/en/user/data/app-schema/secondary-namespace
s.html

Hope this helps!
Ryan




-Original Message-
From: babsip [mailto:babsi...@hotmail.com] 
Sent: Friday, September 10, 2010 3:53 AM
To: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] app-schema: 2 namespaces in one
: how to?


Hi,

in app-schema I need to return a complex feature via WFS that uses XSD-files
with different namespaces. I need to show elements from the "inner" XSD in
the WFS-result.
 
2 XSD files with different namespaces:
* "ProtectedSitesFull_MU.xsd", namespace: "ps" (=  for WFS)
* "GeographicalNamesMU.xsd", namespace: "gn" (= "inner" XSD, used by "ps")

The  "ps:ProtectedSite" is defined in "ps". It includes type
"GeographicalName", which is defined in "gn". I need to explicitly show
"GeographicalName" and some sub-elements (all defined in "gn") in the
WFS-result. Here is how I tried to do this in the mapping-file:


ps:siteName/gn:GeographicalName


GeoServer does not report an error, but delivers a malformed XML-document:
instead of namespace "gn:" it's "null:". Here is part of the result returned
by GeoServer:


  

  

  

  


My questions are:

1. How do I map nested types of different namespaces in ?
2. Tag  in mapping-file: do I need a separate  for
every URI? Or should I put them all into one ? (example see
below)

I'm using GeoServer 2.0.2 with the appropriate app-schema.

Here are snippets of some of the XSDs and the mapping file (I have attached
everything as ZIP-files in case anybody feels like looking at the whole
thing... You will see many parts commented out in the mapping - that was to
reduce the output)

==

ProtectedSitesFull_MU.xsd
-
http://www.w3.org/2001/XMLSchema"; 
  xmlns:ps="http://www.opengeospatial.net/ps"; 
  . . .
  xmlns:gn="http://www.opengeospatial-gmlas.net/gn";
  elementFormDefault="qualified" 
  targetNamespace="http://www.opengeospatial.net/ps";>
  
  . . .
  http://www.opengeospatial-gmlas.net/gn";
schemaLocation="http://www.opengeospatial-gmlas.net/gn/GeographicalNamesMU.x
sd"/>

  
  
  
   
 
...
  
   
  

  

  ...  
  
  
 

  
  ...
  
  
  ...
 

GeographicalNamesMU.xsd
-
http://www.w3.org/2001/XMLSchema"; 
  xmlns:gn="http://www.opengeospatial-gmlas.net/gn"; 
  ...
  elementFormDefault="qualified" 
  targetNamespace="http://www.opengeospatial-gmlas.net/gn";>
  ...
  
  ...


protected_sites_1.xml (Mapping-file)
-
...

  ...
  
gn
  http://www.opengeospatial-gmlas.net/gn
  

...
../../../../schemas/ProtectedSitesMU/catalog.xml
...


   
http://www.opengeospatial.net/ps/ProtectedSitesFull_MU.xsd


   
http://www.opengeospatial-gmlas.net/gn/GeographicalNamesMU.xsd


...
ps:ProtectedSite
...
  


ps:siteName


''






ps:siteName/gn:GeographicalName


''


...

catalog.xml (OASIS-catalog)
---

http://www.opengeospatial.net/ps";
rewritePrefix="INSPIRE/" />
...  
http://www.opengeospatial-gmlas.net/gn";
rewritePrefix="INSPIRE/" /> 


Attachments:
-
complete workspace:  http://old.nabble.com/file/p29675596/ps_folder.zip
ps_folder.zip
XSD-files:  http://old.nabble.com/file/p29675596/schemas.zip schemas.zip 

--
View this message in context:
http://old.nabble.com/app-schema%3A-2-namespaces-in-one-%3CtargetAttribute%3
E%3A-how-to--tp29675596p29675596.html
Sent from the GeoServer - User mailing list archive at Nabble.com.



--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users


--
Automate Storage Tiering Simply

Re: [Geoserver-users] Appschema: NullPointerException

[Ryan Clark]

Victor - Verbose logging was a good idea! The problem was duplicate values
in the backend. The SQL query returned two results, but that would not be
allowed in the schema. Some other part of the system must have decided to
show nothing instead of showing both the results. 

Anyways, deleting one of the rows solved the problem. Thank you!

Ryan



-Original Message-
From: v...@csiro [mailto:victor@csiro.au] 
Sent: Thursday, August 26, 2010 2:04 AM
To: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Appschema: NullPointerException


The mapping looks fine (I assumed the
gsmlcore:metadata is commented out on
purpose and is not the reason for the feature the showing).

perhaps you can try changing the default logging to verbose mode. that
should print out the sql that is being send to the backend. 


--
View this message in context:
http://old.nabble.com/Appschema%3A-NullPointerException-tp29526007p29540267.
html
Sent from the GeoServer - User mailing list archive at Nabble.com.



--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users


--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Appschema: NullPointerException

[Ryan Clark]

Using the 8-25-10 build, I do not get this NullPointer exception. However,
WFS response documents are returning MappedFeatures where the
gsmlcore:metadata element is empty, when it should not be... I've gotten the
service live, so feel free to take a look at http://debug.usgin.org/gsml.
This is running the most recent nightly build.

Empty elements makes me think there's some kind of backend data problem, but
I've double-checked and can't find it. To explain, the isp:MD_Metadata
mapping looks like:

FEATURE_LINK[1]

datasources_id



The chaining from the MappedFeature looks like:

gsmlcore:metadata

datasourceid
isp:MD_Metadata
FEATURE_LINK[1]

false


And this returns empty gsmlcore:metadata elements. However, the SQL Query:
SELECT mapunitpolys.mapunit, datasources.source
FROM ncgmp.mapunitpolys LEFT JOIN ncgmp.datasources ON
mapunitpolys.datasourceid = datasources.datasources_id
WHERE datasources.source IS NULL;
... does not return any records, indicating that every MappedFeature (from
the mapunitpolys table) has an associated MD_Metadata feature (from the
datasources table), but for some reason it is not coming through in the WFS
response.

Thanks,
Ryan



-Original Message-----
From: Ryan Clark [mailto:ryan.cl...@azgs.az.gov] 
Sent: Wednesday, August 25, 2010 8:42 AM
To: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Appschema: NullPointerException

Attached are the mappings I'm using. I double-checked, and there are no null
values in the backend tables relating to this particular attribute mapping.

I'm using a dump from svn trunk that I took about a month ago - not exactly
sure what day it was. Today I'll be trying to set things up in a live
environment with the lastest nightly build.

Thanks for taking a look!
Ryan




-Original Message-
From: v...@csiro [mailto:victor@csiro.au]
Sent: Tuesday, August 24, 2010 11:20 PM
To: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Appschema: NullPointerException


Hi Ryan,

Which build version are you using?

Would you be able to send the mapping files?  I ran into a similar issue in
the past and it was due to null values in the database even though the
schema is set to minOccur=0

I have submitted a patch for this last month

http://jira.codehaus.org/browse/GEOT-2679

Perhaps you can try with the latest version from trunk which is build from
our buildbot :)

http://files.ivec.org/geoserver/geoserver-trunk/2010-08-25/




Ryan Clark wrote:
> 
> Okay - hopefully my last app-schema issue for a while. I certainly 
> appreciate the help!
> 
>  
> 
> My MappedFeature mapping file works perfectly until I add the 
> targetAttribute "gsmlcore:metadata". Here's the mapping:
> 
> 
> 
> gsmlcore:metadata
> 
> 
> 
> datasourceid
> 
> 
> isp:MD_Metadata
> 
> FEATURE_LINK[1]
> 
> 
> 
> false
> 
> 
> 
>  
> 
> Exactly the same mapping works fine within my GeologicUnit mapping 
> file, which also has a gsmlcore:metadata property. Therefore, I don't 
> think that the problem has anything to do with the mapping for the 
> isp:MD_Metadata element.
> 
>  
> 
> When I add this targetAttribute to the MappedFeature file, Geoserver 
> gags on boot, throwing the error shown below. The error goes away if I 
> rename the targetAttribute to something that doesn't exist (e.g.
> "gsmlcore:moustache"),
> but then as you'd expect there's an error when making a feature request. 
> 
>  
> 
> Thanks!
> 
> Ryan
> 
>  
> 
> 24 Aug 12:56:37 INFO [org.geoserver] -
> 
> java.io.IOException
> 
> at
> org.geoserver.catalog.ResourcePool.getDataStore(ResourcePool.java:362)
> 
> at
>
org.geoserver.catalog.impl.DataStoreInfoImpl.getDataStore(DataStoreInfoImpl.
> java:37)
> 
> at
> org.geoserver.config.GeoServerLoader.readCatalog(GeoServerLoader.java:
> 572)
> 
> at
> org.geoserver.config.GeoServerLoader.loadCatalog(GeoServerLoader.java:
> 152)
> 
> at
> org.geoserver.config.GeoServerLoader.postProcessBeforeInitialization(G
> eoServ
> erLoader.java:123)
> 
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanF
> actory 
> .applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBe
> anFact
> ory.java:350)
> 
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanF
> actory
> .init

[Geoserver-users] Appschema: NullPointerException

[Ryan Clark]

Okay - hopefully my last app-schema issue for a while. I certainly
appreciate the help!

 

My MappedFeature mapping file works perfectly until I add the
targetAttribute "gsmlcore:metadata". Here's the mapping:



gsmlcore:metadata



datasourceid

isp:MD_Metadata

FEATURE_LINK[1]



false



 

Exactly the same mapping works fine within my GeologicUnit mapping file,
which also has a gsmlcore:metadata property. Therefore, I don't think that
the problem has anything to do with the mapping for the isp:MD_Metadata
element.

 

When I add this targetAttribute to the MappedFeature file, Geoserver gags on
boot, throwing the error shown below. The error goes away if I rename the
targetAttribute to something that doesn't exist (e.g. "gsmlcore:moustache"),
but then as you'd expect there's an error when making a feature request. 

 

Thanks!

Ryan

 

24 Aug 12:56:37 INFO [org.geoserver] - 

java.io.IOException

at
org.geoserver.catalog.ResourcePool.getDataStore(ResourcePool.java:362)

at
org.geoserver.catalog.impl.DataStoreInfoImpl.getDataStore(DataStoreInfoImpl.
java:37)

at
org.geoserver.config.GeoServerLoader.readCatalog(GeoServerLoader.java:572)

at
org.geoserver.config.GeoServerLoader.loadCatalog(GeoServerLoader.java:152)

at
org.geoserver.config.GeoServerLoader.postProcessBeforeInitialization(GeoServ
erLoader.java:123)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFact
ory.java:350)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.initializeBean(AbstractAutowireCapableBeanFactory.java:1330)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.doCreateBean(AbstractAutowireCapableBeanFactory.java:473)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
$1.run(AbstractAutowireCapableBeanFactory.java:409)

at java.security.AccessController.doPrivileged(Native
Method)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.createBean(AbstractAutowireCapableBeanFactory.java:380)

at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(Ab
stractBeanFactory.java:264)

at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSi
ngleton(DefaultSingletonBeanRegistry.java:221)

at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(Abst
ractBeanFactory.java:261)

at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:185)

at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:164)

at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolv
eReference(BeanDefinitionValueResolver.java:269)

at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolv
eValueIfNecessary(BeanDefinitionValueResolver.java:104)

at
org.springframework.beans.factory.support.ConstructorResolver.resolveConstru
ctorArguments(ConstructorResolver.java:495)

at
org.springframework.beans.factory.support.ConstructorResolver.autowireConstr
uctor(ConstructorResolver.java:162)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.autowireConstructor(AbstractAutowireCapableBeanFactory.java:925)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.createBeanInstance(AbstractAutowireCapableBeanFactory.java:835)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.doCreateBean(AbstractAutowireCapableBeanFactory.java:440)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
$1.run(AbstractAutowireCapableBeanFactory.java:409)

at java.security.AccessController.doPrivileged(Native
Method)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.createBean(AbstractAutowireCapableBeanFactory.java:380)

at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(Ab
stractBeanFactory.java:264)

at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSi
ngleton(DefaultSingletonBeanRegistry.java:221)

at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(Abst
ractBeanFactory.java:261)

at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(

Re: [Geoserver-users] Appschema: Circular feature-chaining

[Ryan Clark]

Thanks Rini - This worked perfectly. I'm curious, could this kind of
configuration help to get around another GeoSciML problem? Specifically,
MappedFeatures cross geometry type boundaries. A MappedFeature might be a
polygon, a line or a point. While this is sensible from the perspective of
an XML document, I'm not sure its viable in the framework of a WFS response
coming from Geoserver.  Certainly at the least, the data source for a
multi-geometry MappedFeature type would have to come from different PostGIS
tables.  

This is just another example of a situation where I previously had to use
two services, one to provide linear MappedFeatures, and one for polygon
MappedFeatures.

Thanks again, and I'm glad to hear the CRS bug has been worked out.
Ryan



-Original Message-
From: Rini Angreani [mailto:rini.angre...@csiro.au] 
Sent: Monday, August 23, 2010 10:51 PM
To: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Appschema: Circular feature-chaining


Hello Ryan,

You can have multiple mappings of a feature type in one service, as long as
they're not in the same location where its featuretype.xml is defined. E.g.
you can't have 2 GeologicUnit mappings in GeologicUnit configuration
location, as the featuretype.xml would not know which mapping to use.
However, you can have a second GeologicUnit mapping file in MappedFeature
folder. That means, only one mapping is used to serve the type as a top
level feature (where featuretype.xml exists), and the other mappings are
only used inside another feature type in a different location/folder.

To achieve this, you can use mappingName
(http://docs.geoserver.org/trunk/en/user/data/app-schema/mapping-file.html#t
ypemappings-and-featuretypemapping).
Sorry the documentation is not clear.. an improvement is long overdue.

So in MappedFeature mapping file, you'd have something like:



gsml:specification


GEOLOGIC_UNIT_ID

geologicUnit_no_Occurrence

FEATURE_LINK



Where geologicUnit_no_occurrence would have no specified attribute mapping
for gsml:occurrence. To make this mapping unique from the top level
GeologicUnit mapping, you must specify  in its
 tag. In this case, mappingName would be
geologicUnit_no_occurrence.
You'd then include the location of geologicUnit_no_occurrence mapping, or
define the FeatureTypeMapping in the same file (and would only exist for
this MappedFeature).

Same deal with GeologicUnit mapping, where you define it separately as a top
level feature, and link occurrences to a separate MappedFeature mapping
(with a different mappingName). Your second MappedFeature would have
specification mapped as xlink:href. 

To sum up, to avoid having errors for multiple mappings per type:
- mappingName has to override existing mapping with the same targetElement. 
- mappingName to be used instead of targetElement in linkElement tag on the
chaining side.  
- there should only be 1 mapping file for the type where it is configured as
top level feature (otherwise you'll get an error about feature type already
exists or something to that effect).

I hope it's not too confusing, and it works for you. Let me know otherwise.

By the way, my colleague Victor Tey is close to fixing the problem you
reported a long time ago: http://jira.codehaus.org/browse/GEOT-2843.


Cheers
Rini


Ryan Clark wrote:
> 
> Hello -
> 
>  
> 
> I've ran into the old circular feature-chaining problem in a GeoSciML 
> WFS service again. Basically it is exactly the problem outlined at
> 
> http://docs.geoserver.org/stable/en/user/data/app-schema/feature-chain
> ing.ht ml#multi-valued-properties-by-reference-xlink-href
> 
>  
> 
> The approach outlined there requires that one or the other, 
> GeologicUnit.occurence or MappedFeature.specification, be by 
> xlink:href all of the time. If I make my occurrences by xlink:href, 
> then whether I make a WFS query for gsml:GeologicUnit or 
> gsml:MappedFeature, the occurrences will always be by xlink:href, and 
> the value may or may not be resolvable, depending on how I construct 
> the string and what exactly is in the WFS response document.
> 
>  
> 
> What you'd really like is a service which followed these rules:
> 
> 1)  GeologicUnits that are being returned as
> MappedFeature.specifications would simply not include the optional 
> gsml:occurrence property.
> 
> 2)  MappedFeature.specifications would only be by xlink:href if those
> MappedFeatures are being returned as GeologicUnit.occurrences.
> 
> 3)  In any other situation, occurrences or specifications would not be
> by xlink:href, unless they were being repeated within a single WFS 
> response document.
> 
>  
> 

[Geoserver-users] Appschema: Circular feature-chaining

[Ryan Clark]

Hello -

 

I've ran into the old circular feature-chaining problem in a GeoSciML WFS
service again. Basically it is exactly the problem outlined at

http://docs.geoserver.org/stable/en/user/data/app-schema/feature-chaining.ht
ml#multi-valued-properties-by-reference-xlink-href

 

The approach outlined there requires that one or the other,
GeologicUnit.occurence or MappedFeature.specification, be by xlink:href all
of the time. If I make my occurrences by xlink:href, then whether I make a
WFS query for gsml:GeologicUnit or gsml:MappedFeature, the occurrences will
always be by xlink:href, and the value may or may not be resolvable,
depending on how I construct the string and what exactly is in the WFS
response document.

 

What you'd really like is a service which followed these rules:

1)  GeologicUnits that are being returned as
MappedFeature.specifications would simply not include the optional
gsml:occurrence property.

2)  MappedFeature.specifications would only be by xlink:href if those
MappedFeatures are being returned as GeologicUnit.occurrences.

3)  In any other situation, occurrences or specifications would not be
by xlink:href, unless they were being repeated within a single WFS response
document.

 

Is there any tricky way to do this? I tried building two gsml:GeologicUnit
mapping files and using one as an includedType in the MappedFeature mapping
file, but this means you have two mappings for one type, and it gags. My
previous incarnation of a GeoSciML service accomplished this by actually
being two services, one for only GeologicUnits, one for only MappedFeatures.
The GeologicUnit service gave back MappedFeature occurrences where the
specification was by xlink:href. The MappedFeature service gave back
GeologicUnit specifications which did not include occurrences at all. This
satisfied my three rules, but meant a lot of maintenance overhead, two
services, and a bunch of duplicate mapping files.

 

If anyone has had any interesting ideas about how to do this, I'd love to
hear them!

 

Thanks,

Ryan

 

 

--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Definitive version of AppSchemaDataAccess.xsd?

[Ryan Clark]

Thanks Ben -

I understand that the XSD is not definitive, and that it is really just a
bit of editing help, nothing more. I also agree that a GUI for editing
configurations would be great, but that's a significant undertaking - it is
not at all straightforward to think of what such an interface would even
look like. In the meantime, the XSD certainly is quite helpful!

I certainly don't understand the ins and outs of the developer's process,
but why couldn't the XSD just be made a part of the app-schema extension
itself? Similar to the way that Geoserver always installs itself with a
bunch of dummy data, couldn't the tutorial data just be included with the
extension?

Thanks,
Ryan





-Original Message-
From: Ben Caradoc-Davies [mailto:ben.caradoc-dav...@csiro.au] 
Sent: Tuesday, August 03, 2010 10:58 PM
To: Ryan Clark
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Definitive version of
AppSchemaDataAccess.xsd?

Ryan,

I have been avoiding this issue for years.  :-)

We use the version in the gt-app-schema test-data as the canonical version:
http://svn.osgeo.org/geotools/trunk/modules/unsupported/app-schema/app-schem
a/src/test/resources/test-data/AppSchemaDataAccess.xsd

Technically, you should use the version matching the release tag of the
build you have.

The XSD is used *only* to aid manual editing of mapping files (they are read
with a non-validating parser). See this warning next to a non-canonical copy
in GeoServer. (I'll be including this in the next update of the app-schema
tutorial):
https://svn.codehaus.org/geoserver/trunk/src/extension/app-schema/app-schema
-test/src/test/resources/test-data/AppSchemaDataAccess.README.txt

The reason the mapping file XSD has not been published is that:

(1) We do not have a suitable persistent place to store it (although I think
we could put it somewhere on geotools.org).

(2) We would have to version it for releases and update it every time trunk
is updated, and this is quite a bit of trouble just for editing help. There
are still some nasty issues (think of a developer making code changes to
trunk pushing out XSD changes to the file while a deployer tries to edit a
mapping file for a trunk snapshot). The underlying problem is that this XSD
lacks a governance process.

(2a) Feel free to use the canonical location in your schemaLocation;
beware: the content and location will change without notice. 
(gt-app-schema is planned to be officially supported and will be moved).

(3) We should have a GUI configuration editor so users do not have to edit
mapping files by hand.

At the moment AppSchemaDataAccess.xsd is subject to least-bad management,
and copies of the file have less failure modes than the other possibilities.

I am open to suggestions if anyone can recommend a better solution.

Kind regards,
Ben.


On 04/08/10 06:32, Ryan Clark wrote:
> I'm wondering if there is a definitive version of the
AppSchemaDataAccess.xsd somewhere? I noticed that the schema that I
downloaded along with the tutorial does not contain the
element. It is really useful to have this schema to work with, just
wondering if there's one floating around that contains the includedTypes?
>
> Thanks,
> Ryan
>
>
>
>


--
Ben Caradoc-Davies  Software Engineering Team
Leader CSIRO Earth Science and Resource Engineering Australian Resources
Research Centre


--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] [ExternalEmail] Re: App-schema and GeoSciML 3.0: cgu:CGI_Term

[Ryan Clark]

Thanks for the help! Creating a cgu namespace/workspace folder, complete
with CGI_Term featuretype, worked great. It also just helps to exemplify the
power of the app-schema extension: I could build simple featuretypes through
the regular Geoserver interface, and then create a complex featuretype that
chains a bunch of the simple ones together.

One thing to make sure appears in your documentation -- the feature-chaining
documentation right now highlights situations where the chained features are
not accessible via regular WFS query. In this case you need to use the
 element in your master mapping file. However when you are
chaining a "complete" featuretype, you don't need to use the 
stuff. This was the only hiccup.

Thanks again,
Ryan



-Original Message-
From: Ben Caradoc-Davies [mailto:ben.caradoc-dav...@csiro.au] 
Sent: Tuesday, August 03, 2010 11:00 PM
To: ryan.cl...@azgs.az.gov
Cc: florence@csiro.au; geoserver-users@lists.sourceforge.net; Jacqueline
Githaiga
Subject: Re: [ExternalEmail] Re: [Geoserver-users] App-schema and GeoSciML
3.0: cgu:CGI_Term

And I owe Jacqui sphinx help so she can get her documentation on this into
the manual. (You are at least the fourth person to be bitten by this, and
the second since it was fixed.)

On 04/08/10 09:22, florence@csiro.au wrote:
> Hi Ryan,
>
> This looks like the "null" prefix error for secondary namespaces 
> problem which has been fix.  Refer to : 
> http://jira.codehaus.org/browse/GEOT-2932
>
> To get it works, you need to create cgu folder in your workspaces folder
with valid namespace.xml and workspace.xml in the cgu folder.
>
> Regards,
> Florence
>
> -Original Message-
> From: Ryan Clark [mailto:ryan.cl...@azgs.az.gov]
> Sent: Wednesday, 4 August 2010 3:42 AM
> To: geoserver-users@lists.sourceforge.net
> Subject: [Geoserver-users] App-schema and GeoSciML 3.0: cgu:CGI_Term
>
> Hello again -
>
> In GeoSciML 3.0, there is a complicated namespace problem I had not 
> encountered in 2.0, and I'm having trouble thinking it through.
>
> Basically, a gsmlcore:GeologicUnit has a gsmlcore:observationMethod 
> property of the type cgu:CGI_TermPropertyType. There was a similar 
> situation in 2.0, but the difference was the property's type was 
> abstract and was still in the gsml namespace (gsml:CGI_ValuePropertyType).
>
> My questions are:
> First, what are the  at the top of the mapping file used 
> for? It appears that they are not passed on to the response document 
> like I had first guessed.
> Second, will I need to create a separate mapping file for the 
> cgu:CGI_Terms because they are in a different namespace than the
gsmlcore:GeologicUnit?
>
> What I've done is:
> - Included a namespace declaration in the  at the 
> beginning of the mapping file:
>   
>   cgu
>   urn:cgi:xmlns:CGI:Utilities:3.0.0
>   
> - Attempted to set the attribute node type and fill out the 
> cgu:CGI_Term content through the following mapping:
>   
>   
>   gsmlcore:observationMethod
>   
>   
>   cgu:CGI_TermPropertyType
>   
>   
>   
>   
>   
> gsmlcore:observationMethod/cgu:CGI_Term/cgu:qualifier
>   
>   
>   xlink:href
>   
> 'urn:cgi:classifier:CGI:ValueQualifier:200811:always'
>   
>   
>   
>   
>   gsmlcore:observationMethod/cgu:CGI_Term/cgu:value
>   
>   
>   xlink:href
>   
> 'urn:cgi:classifier:CGI:FeatureObservationMethod:201001:synthes
> is_fro
> m_multiple_sources'
>   
>   
>
> What I get back is an xml document where the cgu namespace is not 
> declared, and the resulting gsmlcore:observationMethod looks like:
>   
>   
>xlink:href="urn:cgi:classifier:CGI:ValueQualifier:200811:always"/>
>xlink:href="urn:cgi:classifier:CGI:FeatureObservationMethod:201001:syn
> thesis
> _from_multiple_sources"/>
>   
>   
>
> Thank you,
> Ryan
>
>
>
>
>
>
> --
>  The Palm PDK Hot Apps Program offers developers who use the 
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> ___
> Geoserver-users mailing list
> Geoserver-users@li

[Geoserver-users] Definitive version of AppSchemaDataAccess.xsd?

[Ryan Clark]

I'm wondering if there is a definitive version of the
AppSchemaDataAccess.xsd somewhere? I noticed that the schema that I
downloaded along with the tutorial does not contain the 
element. It is really useful to have this schema to work with, just
wondering if there's one floating around that contains the includedTypes?

 

Thanks,

Ryan

 

 

 

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] App-schema and GeoSciML 3.0: cgu:CGI_Term

[Ryan Clark]

Hello again -

In GeoSciML 3.0, there is a complicated namespace problem I had not
encountered in 2.0, and I'm having trouble thinking it through. 

Basically, a gsmlcore:GeologicUnit has a gsmlcore:observationMethod property
of the type cgu:CGI_TermPropertyType. There was a similar situation in 2.0,
but the difference was the property's type was abstract and was still in the
gsml namespace (gsml:CGI_ValuePropertyType).

My questions are: 
First, what are the  at the top of the mapping file used for? It
appears that they are not passed on to the response document like I had
first guessed. 
Second, will I need to create a separate mapping file for the cgu:CGI_Terms
because they are in a different namespace than the gsmlcore:GeologicUnit?

What I've done is:
- Included a namespace declaration in the  at the beginning of
the mapping file:

cgu
urn:cgi:xmlns:CGI:Utilities:3.0.0

- Attempted to set the attribute node type and fill out the cgu:CGI_Term
content through the following mapping:
 

gsmlcore:observationMethod


cgu:CGI_TermPropertyType





gsmlcore:observationMethod/cgu:CGI_Term/cgu:qualifier


xlink:href

'urn:cgi:classifier:CGI:ValueQualifier:200811:always'




gsmlcore:observationMethod/cgu:CGI_Term/cgu:value


xlink:href

'urn:cgi:classifier:CGI:FeatureObservationMethod:201001:synthesis_fro
m_multiple_sources'



What I get back is an xml document where the cgu namespace is not declared,
and the resulting gsmlcore:observationMethod looks like: 






   
Thank you,
Ryan






--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] [ExternalEmail] Re: Geosciml 3.0?

[Ryan Clark]

Thanks for taking a look at this. Ben - I am trying to use the GML 3.1
version. The schema I'm trying to use is here:
https://www.seegrid.csiro.au/subversion/GeoSciML/tags/3.0.0_rc1_gml3.1/geosc
iml-core/3.0.0/xsd/geosciml-core.xsd

Victor - The OpenGeo suite that I'm trying to use runs PostgreSQL on 54321.
I'm pretty sure the database connection works, because everything ran fine
when I was trying to use GeoSciML version 2.0. When I changed to 3.0.0 it
broke...

Again, thanks for the help!
Ryan



-Original Message-
From: Ben Caradoc-Davies [mailto:ben.caradoc-dav...@csiro.au] 
Sent: Thursday, July 29, 2010 7:48 PM
To: v...@csiro
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] [ExternalEmail] Re: Geosciml 3.0?

The stack trace looks more like a schema resolution problem to me.

On 30/07/10 10:37, v...@csiro wrote:
>
> Kindly check your database connection details. Is your postgis port 
> 5432 or 54321? By default postgis I believe is 5432 without the 1


--
Ben Caradoc-Davies  Software Engineering Team
Leader CSIRO Earth Science and Resource Engineering Australian Resources
Research Centre


--
The Palm PDK Hot Apps Program offers developers who use the Plug-In
Development Kit to bring their C/C++ apps to Palm for a share of $1 Million
in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users


--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users