Gotcha. 

I'd wondered how to change the TMS projection to 4326 from 900913. On the old 
GWC site, they indicated the URL format to specify the projection. I ignorantly 
assumed that the projection in the URL was the method by which one requested a 
projection rather than the method by which one declared a projection.

Apologies. This all makes much more sense and I understand all of the mistakes 
I made.

That's what I'm looking to do (change the request from the TMS from EPSG:900913 
to EPSG:4326 - the same request that OpenLayers makes on the GWC demo page for 
EPSG:4326). I'm trying to use Firebug in Firefox to understand how to make that 
request, but am a bit stuck.

Sorry for all of the trouble. I really appreciate your help and patience.

Jeffrey

On 2011-01-03, at 3:21 AM, Arne Kepp wrote:

> The screenshot you included said MERCAT at the bottom. I would assume that 
> means the view is set to mercator, which is EPSG:900913.
> 
> I don't know why you expect it to work to add an EPSG:4326 layer on top of 
> this. GWC mentions the projection as part of the URL, but this is not part of 
> TMS, and so Global Mapper probably depends on you to check that the URL 
> provides tiles in the correct projection.
> 
> -Arne
> 
> 
> On 1/3/11 9:06 AM, Jeffrey McMurtrie wrote:
>> 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