[Geoserver-users] put a geoserver wms on googlemaps view

Hi everybody, now i´m continue doing some testing with googlemaps and geoserver, but now i found i can see my wms further than the google maps view. The thing is here in Panama, there’s some area where the image resolution of google maps its very detailed, and other ones where is very poor, i have some data i want to put in this last area (poor coverage area in googlemaps), but i can because the tiles of googlemaps are only visible until a a very undetailed scale.

How can i make to put my data without it get lost when i go deeper into the image of googlemaps?, someone knows how can i do tu use just the framework of googlemaps without to be tied to the image?, and so, put my own data…?

thanxs in advanced, and warm regards…

http://200.115.174.247/BuboMaps/forms/public/home.aspx

Carlos A. Gordón
Especialista en GIS
Tel. (507) 673-47782
cagb78@anonymised.com
Vía Sonadora, casa 5,
Penonome, Provincia de Coclé
Panamá

Hello,

I’ve seen on the mailing list that this problem has been talked about before, but from the previous mails I could not get a definitive solution for my problem, which is as follows:

I’m using Geoserver 1.6.0 beta4

When I do a WFS GetFeature request (http get)

http://xxx.xxx.xxx.xxx:8080/geoserver/wfs?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&FEATUREID=road.550224

I get my resulting feature with geometry in Lon/Lat, as I expect it:

[…]

<gml:MultiLineString srsName=“urn:x-ogc:def:crs:EPSG:6.11.2:4326”>

gml:lineStringMember

gml:LineString

gml:posList4.89463 52.37444 4.89393 52.37474</gml:posList>

</gml:LineString>

</gml:lineStringMember>

</gml:MultiLineString> […]

When I do a WFS UPDATE of the feature, (leaving the Lon / Lat in the same order)

[…]

wfs:Value

<gml:MultiLineString xmlns:gml=“http://www.opengis.net/gml” srsName=“urn:x-ogc:def:crs:EPSG:6.11.2:4326”>

gml:lineStringMember

gml:LineString

gml:posList4.89463 52.37444 4.89393 52.37474</gml:posList>

</gml:LineString>

</gml:lineStringMember>

</gml:MultiLineString>

</wfs:Value>

[…]

The geometry of the feature is written to the database in the wrong order: Lat / Lon!

Note that the srsName that I get in response to the WFS GetFeature is the same as I use in the WFS Update.

Is there a (quick) fix to solve my problem?

With kind regards,

Lex Tiekink

AND Automotive Navigation Data

carlos gordon ha scritto:

Hi everybody, now i´m continue doing some testing with googlemaps and geoserver, but now i found i can see my wms further than the google maps view. The thing is here in Panama, there's some area where the image resolution of google maps its very detailed, and other ones where is very poor, i have some data i want to put in this last area (poor coverage area in googlemaps), but i can because the tiles of googlemaps are only visible until a a very undetailed scale.

How can i make to put my data without it get lost when i go deeper into the image of googlemaps?, someone knows how can i do tu use just the framework of googlemaps without to be tied to the image?, and so, put my own data...?

I don't know if you can replace Google images, I doubt it, but to
make sure you should ask on the Google forums here:
http://groups.google.com/group/Google-Maps-API

Anyways, if you're playing just with Google raster data, you can
just "cover" it with yours when the zoom is sufficiently big.
You can do that by putting a raster layer in geoserver and specify
in its associated SLD a minumum scale denominator.

Let me know if this works for you
Cheers
Andrea

Hi Lex,

Andrea can give you a definitive answer but I suggest you try out rc1.
All the wfs 1.1 axis order issues have been solved there since beta4.

-Justin

Lex Tiekink wrote:

Hello,

I’ve seen on the mailing list that this problem has been talked about
before, but from the previous mails I could not get a definitive
solution for my problem, which is as follows:

I’m using Geoserver 1.6.0 beta4

When I do a WFS GetFeature request (http get)

http://xxx.xxx.xxx.xxx:8080/geoserver/wfs?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&FEATUREID=road.550224
<http://xxx.xxx.xxx.xxx:8080/geoserver/wfs?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&FEATUREID=road.550224&gt;

I get my resulting feature with geometry in Lon/Lat, as I expect it:

[…]

<gml:MultiLineString srsName="urn:x-ogc:def:crs:EPSG:6.11.2:4326">

  <gml:lineStringMember>

    <gml:LineString>

      <gml:posList>4.89463 52.37444 4.89393 52.37474</gml:posList>

    </gml:LineString>

  </gml:lineStringMember>

</gml:MultiLineString> […]

When I do a WFS UPDATE of the feature, (leaving the Lon / Lat in the
same order)

[…]

  <wfs:Value>

    <gml:MultiLineString xmlns:gml="http://www.opengis.net/gml&quot;
srsName="urn:x-ogc:def:crs:EPSG:6.11.2:4326">

      <gml:lineStringMember>

        <gml:LineString>

          <gml:posList>4.89463 52.37444 4.89393 52.37474</gml:posList>

        </gml:LineString>

      </gml:lineStringMember>

    </gml:MultiLineString>

  </wfs:Value>

[…]

The geometry of the feature is written to the database in the wrong
order: Lat / Lon!

Note that the srsName that I get in response to the WFS GetFeature is
the same as I use in the WFS Update.

Is there a (quick) fix to solve my problem?

With kind regards,

Lex Tiekink

AND Automotive Navigation Data

!DSPAM:4007,473dc63b303115219720167!

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

!DSPAM:4007,473dc63b303115219720167!

------------------------------------------------------------------------

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

!DSPAM:4007,473dc63b303115219720167!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Lex Tiekink wrote:

Hello,

I've seen on the mailing list that this problem has been talked about
before, but from the previous mails I could not get a definitive solution
for my problem, which is as follows:

I'm using Geoserver 1.6.0 beta4

When I do a WFS GetFeature request (http get)

http://xxx.xxx.xxx.xxx:8080/geoserver/wfs?SERVICE=WFS
<http://xxx.xxx.xxx.xxx:8080/geoserver/wfs?SERVICE=WFS&VERSION=1.1.0&REQUEST
=GetFeature&FEATUREID=road.550224>
&VERSION=1.1.0&REQUEST=GetFeature&FEATUREID=road.550224

I get my resulting feature with geometry in Lon/Lat, as I expect it:

[.]

<gml:MultiLineString srsName="urn:x-ogc:def:crs:EPSG:6.11.2:4326">

  <gml:lineStringMember>

    <gml:LineString>

      <gml:posList>4.89463 52.37444 4.89393 52.37474</gml:posList>

    </gml:LineString>

  </gml:lineStringMember>

</gml:MultiLineString> [.]

When I do a WFS UPDATE of the feature, (leaving the Lon / Lat in the same
order)

[.]

  <wfs:Value>

    <gml:MultiLineString xmlns:gml="http://www.opengis.net/gml&quot;
srsName="urn:x-ogc:def:crs:EPSG:6.11.2:4326">

      <gml:lineStringMember>

        <gml:LineString>

          <gml:posList>4.89463 52.37444 4.89393 52.37474</gml:posList>

        </gml:LineString>

      </gml:lineStringMember>

    </gml:MultiLineString>

  </wfs:Value>

[.]

The geometry of the feature is written to the database in the wrong order:
Lat / Lon!

Note that the srsName that I get in response to the WFS GetFeature is the
same as I use in the WFS Update.

Hi,
the problem lies in axis order issues that beta4 did not address properly.
First and foremost, when you're using urn:x-ogc:def:crs:EPSG:6.11.2:4326 the
axis order is lat/lon, that's by OGC specification and we cannot do anything
about it.
Beta4 had some issues and mixed axis order depending on the operation you
used, rc1 should be consistent, so:
* every time you get back your data from a WFS 1.1 GetFeature you'll receive
them back in lat/lon by default.
* every time you do an update/insert and do not specify the srsName,
GeoServer will assume data is in lat/lon order
* every time you use urn:x-ogc:def:crs:EPSG:6.11.2:XXXX way of stating a CRS
it will be in lat/lon order (by OGC spec)
* for backwards compatibility with the pre WFS 1.1 world, if you use
EPSG:XXXX or http://…:XXXX ways of expressing a CRS GeoServer will
interpret them as lon/lat instead. Given that WFS 1.0 do use those two
forms, with WFS 1.0 you'll still be using lon/lat formatted data.

I know it's messy, but that's the direction OGC is taking. In WFS 1.2 the
only accepted form of expressing an SRS will be
urn:x-ogc:def:crs:EPSG:6.11.2:xxxx so everybody will be stuck with lat/lon
ordered data.
And btw, that's the specification INSPIRE is going to mandate (that matters
to you if you live in europe) along with WMS 1.3, which again works only
with lat/lon data (for example you'll have to express the bbox in lat/lon
order).

Hope this clarifies a little the issue. I will try to write a wiki page
explaning the issue more in deep before we release GeoServer 1.6.0 final.

Cheers
Andrea

--
View this message in context: http://www.nabble.com/Lon---Lat-in-difrerent-order-between-WFS-insert-and-GetFeature--tf4822466.html#a13839361
Sent from the GeoServer - Dev mailing list archive at Nabble.com.