Sorry about my poor description!

Okay, my client is Global Mapper (the newest build has TMS support added).

To produce the problem I'm seeing I can do the following:
1) Create a new map with the projection set to EPSG:4326
2) Add the TMS with the following URL: 
http://69.$$$.$$$.143:8080/geoserver/gwc/service/tms/1.0.0/LIO:r...@epsg:4...@png/
3) Add a shapefile of the same data set (in a different projection, though 
Global Mapper can auto-reproject it).

As in the image I attached before, the 2 data sets aren't aligned - if I check 
the co-ordinates of any identical point, the GeoServer WMS data set is way off 
while the shapefile is correct (ie a point on the western boundary of the data 
set as approximately 52 degrees north and 95 degrees west while the data 
retrieved from the WMS shows that same point as approximately  72 degrees north 
and 10 degrees west)

If I do the following it works fine:
1) Create a new map with the projection set to EPSG:900913
2) Add the TMS with the following URL: 
http://69.$$$.$$$.143:8080/geoserver/gwc/service/tms/1.0.0/LIO:r...@epsg:900...@png/
3) Add a shapefile of the same data set (in a different projection, though 
Global Mapper can auto-reproject it).

Essentially, if I do the same thing with EPSG:900913 there are no issues.

Thinking about it, I wondered if it was the client. OpenLayers gives the 
correct co-ordinates with EPSG:4326. Unless I screwed up my URL formatting 
somehow (which I don't believe is the case) then that seemed the most likely 
cause of the problem. So I downloaded uDig and added the TMS and then the 
shapefile. It worked correctly!

So it looks like it's Global Mapper screwing up.

Jeffrey



On 2011-01-03, at 1:53 AM, Arne Kepp wrote:

> I'm not really sure what that picture is showing. Are you viewing tilesets 
> for EPSG:4326 and EPSG:900913 at the same time? That's not expected to work, 
> unless your client reprojects the tiles.
> 
> You should probably explain what software you are using, and include 
> screenshots of how the different overlays are configured.
> 
> ( GWC does not do reprojection, it just stores the output from GeoServer, but 
> in this case it does the TMS to WMS translation. )
> 
> -Arne
> 
> 
> On 1/2/11 10:57 PM, Jeffrey McMurtrie wrote:
>> I just recently discovered GeoServer. It's wonderful! For a long time
>> I'd been wishing there was something like it, so finding it was a
>> wonderful Christmas gift!
>> 
>> Now on to the slight problem I've been having. In order to speed
>> things up, I decided to use GWC's TMS. It works correctly with EPSG:
>> 900913, but not with EPSG:4326. EPSG:4326 seems not to be reprojected
>> properly.
>> 
>> My TMS URL format that has the issue: http://69.$$$.$$$.143:8080/
>> geoserver/gwc/service/tms/1.0.0/LIO:r...@epsg:4...@png/ (The middle 2
>> sets of numbers in my IP are intentionally swapped with $$$ for this
>> example)
>> 
>> A visual of the problem:
>> 
>> http://www.algonquinmap.com/temp/Geoserver.jpg
>> 
>> On the left you can see a shapefile that wasn't sent through GeoServer
>> as well as a roads layer that was (using EPSG:900913). On the right
>> you can see the problem... when I swap EPSG:900913 out with EPSG:4326,
>> the data isn't projected properly.
>> 
>> For what it's worth, I'm wanting to use EPSG:4326 since the WMS Store
>> which I'm getting some of the data from seems to have problems
>> providing data in EPSG:900913 (some tiles aren't downloaded and appear
>> as question marks when testing out the layer in OpenLayers on the GWC
>> demo page), plus I'm finding that when using EPSG:900913 I'm getting
>> white lines through the tiles.
>> 
>> Thanks in advance! I hope it's not a stupid question, but I've spent a
>> day or so fiddling around and searching Google and the list archives
>> for an answer to no end.
>> 
>> Cheers,
>> 
>> Jeffrey
>> 
>> ------------------------------------------------------------------------------
>> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
>> to consolidate database storage, standardize their database environment, and,
>> should the need arise, upgrade to a full multi-node Oracle RAC database
>> without downtime or disruption
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Geoserver-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
> 


------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Reply via email to