Add lat/long versus relative support

[kmbisset89]

This is an awesome start to a map engine. But if we had geotiff's we would have to make another application to make them in the file format necessary for this. If you allow for lat long support that would make this more expandable.

[rt-bishop]

For conversion between lat/lon and x/y(0,1) you could use something like this:

fun Double.latToY01(): Double {
    val sinus = sin(clipLat(this) * PI / MAX_LONGITUDE)
    return 0.5 - ln((1 + sinus) / (1 - sinus)) / (4 * PI)
}

fun Double.lonToX01(): Double {
    return (clipLon(this) - MIN_LONGITUDE) / (MAX_LONGITUDE - MIN_LONGITUDE)
}

fun Double.y01ToLat(): Double {
    return 90 - 360 * atan(exp((this - 0.5) * 2 * PI)) / PI
}

fun Double.x01ToLon(): Double {
    return MIN_LONGITUDE + (MAX_LONGITUDE - MIN_LONGITUDE) * this
}

Ref code. I do agree though it would be great to have this inside the library with the checks for exceeding the MIN/MAX values.

[p-lr]

This library isn't tied to any measurement system. A map could be taken from a scanned paper or may represent the whole world. In the latter case, lat/lon make sense. However lat/lon may be irrelevant in other use cases.
Also, the relative to lat/lon formulas depend on the projection used to make the map.

Please provide more details about your usage of the library.

[Nohus]

To share a use case, I'm using the library for a map that uses a different coordinate system (EPSG:2180), so support for GPS in particular wouldn't be useful to me, and I know many countries have their own coordinate systems for their maps. Where a case could be made, is to have the library accept a conversion interface so you can then use your own coordinate system and have the library call your conversion internally. But I don't think it would be that much more useful than just doing it yourself.

…

On Thu, 21 Sept 2023, 18:47 Pierre Laurence, ***@***.***> wrote: This library isn't tied to any measurement system. A map could be taken from a scanned paper or may represent the whole world. In the latter case, lat/lon make sense. However lat/lon may be irrelevant in other use cases. Also, the relative to lat/lon formulas depend on the projection used to make the map. Please provide more details about your usage of the library. — Reply to this email directly, view it on GitHub <#95 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUNLQE5UZIWGJQ3MKYURJ3X3SDVXANCNFSM6AAAAAA5AVYKDE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[kmbisset89]

@Nohus I am guessing that you just figured out how to put your projection on the Number of Block - Width x Number of Blocks -Height and figured out how to stack your imagery there. I will investigate putting WGS-84 on the map. The renderer of this map does seem really good to try and figure that out.

When I do that I can try and figure out each boxes bound points of lat and long and determine image coverage. Sorry I am talking this out loud so that it might paint a better picture. Then I can associate zoom to the respective 1:Altitude ratio of the imagery.

[p-lr]

Typically you know the extent in latitude and longitude of what you're rendering. Let's say Ya and Yb are respectively the projected coordinate in Y dimension of the top and the bottom. When y is a relative coordinate, it's projected coordinate in Y dimension is is Ya + y*(Yb-Ya). Then, the corresponding latitude is obtained using the relevant formula (which depends on the projection).

[kmbisset89]

I am not sure I understand completely but I will try my best to see what I can do. I understand the relative calculation, but I am trying to think of how to get the "blue marble map" to project correctly

[kmbisset89]

I think I will have to split bitmaps over a projection.