Map centered on the 180° meridian
Real time satellite tracking and orbit prediction
Status: Beta
Brought to you by:
csete
Menu
▾
▴
#22 Map centered on the 180° meridian
The map view should allow users to center it around other longitudes than 0.
This should be controlled by user configuration option.
To the extent possible, it should use the existing maps.
See discussions at http://forum.oz9aec.net/viewtopic.php?f=9&t=79
Please find attached a new image. It is of a mockup of a possible 180 degree meridian implementation. Actually, as currently implemented it should support centering on any arbitrary meridian.
It uses an image generated by xplanet as the background. This allows arbitrary placement of the center of the map. It also uses a keyfile associated with the image (imagefilename.meta) to store the leftmost extent of the image. If there is no meta data it assumes the map is centers on the prime meridian.
The recipe still needs testing, but comments would be nice.
I am hesitant to reuse the existing files inside gpredict for two reasons. First is that it is easy to generate them with xplanet. The more driving reason is that I hope to support additional projections with arbitrary centers in longitude and latitude and arbitrary latitudes with other projections are not as clean.
PS, for a shortcut to implementing showing daylight, xplanet will create and update an image file that has the daylight embedded. If in sat-map view we store the file modified time, check it each update, and update accordingly, the effect would work. There may be caveats about file locking that this does not address. Is this worthwhile pursuing?
180degree meridien screenshot.
I am probably missing something but I can't figure out why you want to use xplanet for this.
As I understand from your screenshot, you have already added code to properly place the satellites, qth and grid lines in gpredict. So the only tasks left for xplanet is to "shift" the background map. If I'm not mistaken, this can be done with a few lines of code using gdk_pixbuf_composite(). Even if it's not this simple, I doubt I will accept introducing a new external dependency for this conceptually simple task.
Example implementation of load_map_file() that takes center longitude as parameter.
gdk_pixbuf_composite() is usable but gdk_pixbuf_copy_area() is simpler. I have attached an example implementation of load_map_file() that shifts the map according to the center longitude parameter. It is straightforward and not optimized at all to allow tracing the logic.
Example implementation that uses metadata about image and updates map.
To be clear, I was not suggesting that xplanet be a dependency. Merely that the user be able to create custom maps (perhaps time varying) and be able to import them into gpredict as basemaps for the satmap view. xplanet is but one way of creating such images. Metadata would be required to correctly place items on the map. However the user should not be constrained by the data formats.
That said, my implementation is attached. It loads an image file. Checks if there is metadata for that file and loads the left most edge from that metadata. (if meta data does not exist it assumes the old format.) It then uses that left most edge to compute the grid, the satellite footprint and the qth placement. Changes were needed in the load, xy_to_lonlat, lonlat_to_xy, and mirror_lon functions. I ran these for 12 hours using the amateur module with maps centered at 0, 90, 180 and -90 degrees and saw no crashes or odd visual effects. Again these index of the left edge instead of the center.
Ok, I understand better now, though I'm still puzzled why you prefer that users to provide their own maps and metadata if they want to use this feature. I think that would be a severe limitation to require providing a map which then would only work for one longitude.
Here is how it should work:
(1) User goes to preferences -> map view
(2) User enters longitude that should be at the center of the map
(3) User can also select another map here and the option already exists to use custom maps (but map files must have center at 0 longitude)
(4) Gpredict loads the map and performs the translation according to the longitude chosen in (2)
(5) Gpredict draws the qth, the satellites and the grid according to the the longitude chosen in (2)
You have already done (5) and I have provided (4). The only thing left is to add a config option where the user can select the longitude and we are done. The same map file will work for any longitude.
Ok, I understand better now, though I'm still puzzled why you prefer that users transform available data to a fixed gpredict coordinate system. I think that would be a severe limitation to users wanting to use other data.
Now that I have that out of my system.
I think the correct solution long term is to have a GIS widget that can transform data from with any metadata to any coordinate system. Frankly, it is something I hope we can leverage from other sources than have to write our own. With the abundance of data sources, OSM, NASA, USGS, and others, we need to be able to accept all the data eventually.
I think you underestimate the difficulty of step 4. The snippet you provided has implicit limitations. The shifting will only be correct if (center-180.0)*(image width in pixels)/360.0. For the 800 pixel wide image included in gpredict this would not allow centers of 30 degrees or sixty degrees.
As such, allowing the user to render the data correctly externally and pull it in seems the way to get it to work show. Also there are already tools available to the user doing so, so it does not seem a high hurdle to put in front of the user.
Looking forward, I expect there to be shifts in latitude and alternative projections. For the mercator projection, these will not be a problem. However with lambert projections, these are not a simple shift and require recalculations. Also with an azimuthal projection, the image is only valid for the one place on earth where it is rendered from.
Also, nothing keeps us from shipping additional images.
It also makes it render correctly in the select map dialog. Perhaps that should be 1.5
Gpredict only supports one coordinate system with one projection and users are locked to that one regardless of whether it is Gpredict or an external application that transforms the map. Try to understand that the only difference between your proposal and mine is whether the map transformation should be done inside Gpredict or outside.
My map transformation code is supposed to be generic and work for any map width and any longitude. I tried it with an 800x400 map, longitudes 30 and 60 (and a bunch of others) and it works correctly.
Bringing other projections into the discussion is irrelevant and belongs to a different topic. If we want to support other projections, we would still have to modify Gpredict to properly place qth and satellites, so it will not be the map transformation function that will pose the limitation.
There are other feature requests asking for other projections. That can be addressed there.
I still do not see how you get around around the fact that for a 800 pixel wide the 30 degree meridien is 1/3 of the way from a pixel edge and the center of the image is on a pixel edge. This seems a fundamental rendering problem.
The correct solution would seem to be interpolate to a new sampling lattice which put the 30 degree meridien on a pixel boundary.
What am I missing?
There was a single vertical line at the right edge of the map which was misrendered. This was due to a rounding error cause by typecast from float to integer and occurred for all map sizes and all longitudes (except 0). The solution is to do proper rounding instead of typecasting. I see no other rendering errors.