Support for worldwide base layers

[elafargue]

This is more a question than an actual issue (congrats on this project by the way!): is there anything that prevents PolaricServer webapp from using OSM or Google Openlayers layers, apart from the fact support is not in the compiled javascript?

It would be great to offer a basic OpenStreetmaps or Google Maps "worldwide" layer to allow users outside of Europe to try Polaric Server. If I implement this, I will submit a pull request...

[elafargue]

Using stock OpenLayers 2.13.1, it is very straightforward to display a world map - just tried, works great. Unfortunately all stations seems to have 0,0 coordinates, trying to understand whether this is due to OpenLayers or if the error comes from somewhere else.

[elafargue]

After some more work, it seems one of the problems is that OSM and Kartverket projections are different... any hint as to how to configure other map types?

[ohanssen]

A agree it would be great to be able to use other map sources using other projections. For example OSM.

When we started this project maps from Kartverket was in the UTM (zone 33) projection only. Also, we wanted to use a projection that corresponds directly to the paper maps used by rescue personnel in the field. The advantages of using a UTM projection instead of a standard mercator projection is maybe clearer in the arctic areas. However, now, Kartverket supports the Google projection as well and it might be a better choice for some.

It is possible to configure a Polaric Server instance to use another UTM zone than the default 33W, but to let the same server instance use multiple zones and possibly switch automatically between them would require some hacking. This could be the first step? Supporting other projections than UTM would require some more changes..

The positions of stations or objects (in XML overlays) are UTM coordinates, and assume that one single UTM zone is chosen for the server. This does not prevent us from using more that one zone for maps (OpenLayers).

I just checked in some changes to polaric-aprsd to eliminate the need to lock it to a single UTM zone and to allow the client to pass a UTM zone dynamically with each HTTP request.

[elafargue]

That was quick :-) Thanks. Yes, I see your point about standard Mercator not being ideal in the North!

[ohanssen]

Well. I have to do some more hacking to get it working correctly. I'll commit it tonight for aprsd. And the client code need to be fixed as well.

[ohanssen]

I committed some changes to webapp. The UTM zone can be changed just by editing mapconfig.js.

[elafargue]

Just checked out the latest version: much better behaviour now, but it looks like the x1-x4 parameters sent by the webapp are strange - they resolve to lat values that are above -90/90...

I set mapconfig.js to UTM zone 10 and using projection EPSG:32610 .

A typical request around the San Francisco region asks for this bounding box: x1:-13717014 x2:4451490 x3:-13514608 x4:4570426 filter:track scale:433343 clientses:7 utmz:10

[ohanssen]

If the bounding box goes far west of the chosen UTM zone the x values will be negative. But if you just show the California area I guess this should not happen. I just tested with a canadian WMS with UTM zone 10 and it works nicely and I can display APRS data correctly.

[elafargue]

Yes, I think most of my issues are linked to the fact I am using OpenStreetMaps which does not use a UTM projection, so the extents have to be remapped to our UTM projection.

kaMap line 986: var b = this.olMap.getExtent().transform(this.olMap.getProjection(), this.olMap.displayProjection);

On Tue, Oct 28, 2014 at 12:54 PM, LA7ECA, Øyvind Hanssen < notifications@github.com> wrote:

If the bounding box goes far east of the chosen UTM zone the x values will be negative. But if you just show the California area I guess this should not happen. I just tested with a canadian WMS with UTM zone 10 and it works nicely and I can display APRS data correctly.

— Reply to this email directly or view it on GitHub https://github.com/PolaricServer/webapp/issues/1#issuecomment-60820334.

[ohanssen]

Ah. I see. The tiles are reprojected when the base layers have a different projection than what is set as default. I see I do this transform in some other functions but forgot to do it in this function so you found a bug.

[ohanssen]

I checked in some changes. UTM baselayers can now be mixed with spherical mercator baselayers (like OSM) and switching between them works ok. I had to do some work to re-center the maps with reprojected coordinates and adjust the scale at higher latitudes.

[elafargue]

That's great! I'll Check it out ASAP

Ed On Dec 15, 2014 1:43 PM, "LA7ECA, Øyvind Hanssen" notifications@github.com wrote:

I checked in some changes. UTM baselayers can now be mixed with spherical mercator baselayers (like OSM) and switching between them works ok. I had to do some work to re-center the maps with reprojected coordinates and adjust the scale at higher latitudes.

— Reply to this email directly or view it on GitHub https://github.com/PolaricServer/webapp/issues/1#issuecomment-67071358.

[ohanssen]

Ok, with the lastest updates I consider this as resolved and close this issue. There are some issues when crossing the dateline but it seems to depend on the projection how this can be solved.