• 123 Posts
  • 880 Comments
Joined 2 年前
cake
Cake day: 2023年6月15日

help-circle










  • The have a paid sdk for businesses, not for endusers, Magic Earth is just a byproduct.

    Magic Earth is free for all our end-users but we also have a paid Magic Earth SDK for business partners. For instance Selectric.de (a supplier for navigation solutions for ambulances and fire trucks), Smarter AI (developing ADAS systems) or Absolute Cycling (using the platform on bicycles). For more info on the SDK, you can check magiclane.com.

    They also collect anonimized traffic data from users:

    We send position data to our traffic provider to generate real-time traffic information. The data is anonymized on the phone, using a changing key (so it’s not linked to you), and it is deleted after 5 minutes.

    Both info is from their faq: https://www.magicearth.com/faq-en/




  • Afaik windows on arm is still very limited, a lot programs still only support x86.

    And touch ux on linux is not very convenient, I have a touch laptop and have used it with gnome for years, and it has a lot rough edges. Can a linux enthusiast use it? Sure. Would I recommend it to non computer savvy user? No, they won’t enjoy it.

    I tried xfce about a year ago on an old intel atom x86 tablet, it was not usable at all. I read Gnome is the most advanced in touch support, I don’t know how touch friendly is kde nowadays.

    So on windows a user would be limited to basic apps, android has much more options.









  • It definitely shows lake names, it’s just limited to specific zoom levels, e.g. here you should see all the names of the Great Lakes: https://www.openstreetmap.org/#map=7%2F45.064%2F-81.758

    The source code of the renderer is here: https://github.com/gravitystorm/openstreetmap-carto

    And there is an issue about displaying sea and ocean names: https://github.com/gravitystorm/openstreetmap-carto/issues/2278

    Some comments from the issue:

    Rationale from @gravitystorm@m.gravitystorm.co.uk as an issue comment:

    We need to be careful with these labels, for a few reasons. Using a single point to represent an ocean is quite an oversimplification! These points are also arbitrarily placed, so mappers could get into endless edit wars about where to put them. Many mappers will use them as “labelling positions” rather than ensuring the position has some kind of geographic basis.

    The Arctic Ocean label is a good example. From the overpass screenshot I assume the node is outwith the range we render. Do we want just the bottom half of the label showing?

    Normally oceans and sea labels are “hand placed” by cartographers, since the challenge of automating the label placement is so high. But we can solve the technical challenges here; while doing so lets remember not to end up rendering “labelling nodes” by mistake.

    Another good reason why it’s a complex topic:

    The problem with mapping oceans and seas is verifiability - mapping them as nodes is the simplest way to have the tags, in particular the names in various languages, in the database (which are verifiable). The coordinates are essentially meaningless.

    Summary here:

    I think we have already established in the above discussion and in #2345 that we do not want to render sea and ocean labels based on mapper placed geometries from the OSM database (either nodes or polygons) and thereby have the map painted by mappers based on subjective preferences and the specifics of the labeling style here and the mercator projection.

    IMO there are two decent options:

    • render by combining the tagging from place nodes in OSM with hand placed labeling geometries based on cartographic considerations for this style (like done by Label oceans and large seas from a static file #2345). This is feasible for oceans but not for seas due to the number of features. Special consideration should be given to avoiding vandalism in combination with slow low zoom update cycles.
    • auto-generate labeling geometries based on place nodes and the (simplified) coastline geometry. This is more challenging but would scale better.

    In both variants i would only use place nodes to specifically discourage mappers from pointless polygon drawings. There is simply no case where for a sea or ocean a polygon is the most suitable way to map in OSM.