[HN Gopher] Apache Baremaps: online maps toolkit
___________________________________________________________________
Apache Baremaps: online maps toolkit
Author : l3x
Score : 76 points
Date : 2023-05-28 18:53 UTC (4 hours ago)
(HTM) web link (baremaps.apache.org)
(TXT) w3m dump (baremaps.apache.org)
| LeoNatan25 wrote:
| Just scrolling around Israel, it seems text rendering for RTL is
| broken.
|
| https://demo.baremaps.com/#12.91/32.06932/34.75969
|
| Should be "tl byb", not "byb lt". How do these issues even exists
| in 2023? Is a team building these renders not aware of RTL
| languages, or do they just not bother implementing it?
| tiberious726 wrote:
| > "How do these issues even exists in 2023?"
|
| Have actually tried writing something that handles languages
| running in different directions? It might be 2023, but the
| libraries... aren't great...
| LeoNatan25 wrote:
| From my experience (not on the web), frameworks that take
| their Unicode support seriously fare quite well by now
| (nothing is perfect), while frameworks that make silly
| assumptions that everything is ASCII do not.
| LeoNatan25 wrote:
| Opened an issue on GitHub for this:
| https://github.com/apache/incubator-baremaps/issues/679
| bchapuis wrote:
| Thank you for reporting this problem, I created an issue on
| GitHub to track it. The root cause is probably located in our
| tileset or style (not in the renderer). Right now, we use the
| OpenStreetMap name attribute in our tiles and most of our tests
| are performed in central europe.
| LeoNatan25 wrote:
| Thanks. Just verified, and OSM is correctly rendering RTL (at
| least Hebrew).
| [deleted]
| makeitdouble wrote:
| > How do these issues even exists in 2023?
|
| As long as the core developpers of the new platform live and
| work on the US west coast, any issue non relevant to the US
| will be a second class citizen, mostly dealt with after the
| product is deemed stable.
|
| The same way OpenAI operates in english first and other
| language systems will be improved "later".
|
| It's not a jab on the devs, I realistically can't see any other
| approach. Just another angle where there's no free lunch and
| more investment is needed building systems that aren't US first
| if we care about non-US needs being met in a timely manner.
| abusaidm wrote:
| This is a great addition to the space. Do you plan to fill the
| gap left by mapbox for the open source community?
|
| Things like map libs for mobile and the web with advanced things
| like 3d, navigation, elevation and the likes?
|
| I feel like we need a go to solution that unchains away from the
| commercial solutions to power osm solutions across devices and
| use cases.
| bchapuis wrote:
| Yes, there is clearly a need for a go-to solution. MapLibre and
| Cesium are doing a great job with their open-source renderers.
| Baremaps complements this by providing open infrastructure
| components, such as a data pipeline and a vector tile server.
| For instance, another missing piece in this space is an open-
| source IP to location solution. Our current prototype is
| rudimentary but demonstrates that this gap can be filled.
| pininja wrote:
| I'm a maintainer for vis.gl (deck.gl and react-map-gl), and
| am existed you're focusing on infrastructure components. Open
| data and nav/location solver services are key for many
| applications, and today most options for what I'd consider
| "the basics" are proprietary/commercial. I'm all for paying
| for good work.. but I'd like to see the funds go towards
| bleeding edge, and see long-established solutions become open
| and easy to use.
| bchapuis wrote:
| Clearly, I did some location-based pub/sub research in the
| past and the lack of open source infrastructure components
| was an important motivation for Baremaps. Today, the open
| source ecosystem in this area is moving fast and I think we
| are pretty close from a having high quality options for all
| the main infrastructure components (map, geocoder, reverse
| geocoder, ip to location, routing, TSP, etc.).
| mtrcn wrote:
| Looks promising, I have published a paper about workflow systems
| in geospatial data processing
| (https://www.mdpi.com/2220-9964/11/1/20). I wonder if I can use
| this project to realize proposed system in my paper.
| bchapuis wrote:
| Nice, thank you for the pointer. Our workflow uses a DAG and
| the format is loosly inspired by GitHub actions and AWS data
| pipeline. This is an area we seek to improve, so no not
| hesitate to reach out on GitHub or by email.
| bchapuis wrote:
| Hi, author here, I just noticed that Baremaps was submitted to
| HN. Our demo runs on PostGIS, and I'm surprised it's holding up
| under the load. I'm happy to answer questions.
|
| Here is the fullscreen demonstration for those who are
| interested. https://demo.baremaps.com/
| Waterluvian wrote:
| As a geographer who migrated to mobile robotics and web
| mapping, I've found that there is a lack of "serious" web
| spatial analysis tools for in-browser work. Think the
| geotoolbox you get in ArcGIS or QGIS for building analytical
| processing pipelines for raster and vector datasets,
| particularly from web sources.
|
| Lately I've revisited the idea and found that with wasm,
| SharedArrayBuffer for parallelism, and more maturing libraries,
| it may be possible to provide a much richer set of analytical
| tools.
|
| Is this an idea you've explored? This would be my "if I won the
| lottery, what would I work on?" project.
| bchapuis wrote:
| Have you tried Turf.js? It goes pretty far when it comes to
| in-browser spatial analysis. Baremaps is more about the
| server side of web mapping. We currently use MapLibre for
| rendering the vector tiles we produce in the browser and plan
| to support 3d tiles in the future.
| Waterluvian wrote:
| I should try Turf again. The core problem last time was
| that it fundamentally does not support "Simple"/ Euclidean
| coordinate systems. When I want to do analysis on flatland
| indoor maps, it does all the math wrong.
| jaipilot747 wrote:
| When would I use Baremaps versus something like GeoServer?
| bchapuis wrote:
| Hi, author here, Baremaps aims to create an open and easily
| extensible vector map, inspired by OpenStreetMap Carto. The
| goal is to provide a high-quality base map for the planet.
| Since we use PostGIS as a storage backend, you can extend it
| with your own layers and data.
| Freak_NL wrote:
| I hope your planning on going _beyond_ what Carto does.
| Baremaps currently doesn 't render highway=busway either,
| leading to awkward gaps in the map. It's an accepted tag
| supported in every renderer _except_ Carto (look at OsmAnd or
| Organic Maps for instance), because the two or three active
| maintainers remaining (having lost a number of maintainers in
| the past two years) don 't like the tag. Carto has pretty
| much stagnated despite its past achievements.
|
| As the default renderer for openstreetmap.org, Carto is
| currently an embarrassment for OpenStreetMap.
| bchapuis wrote:
| Thank you for describing this issue, I created an issue on
| GitHub to track it. The fact that OpenStreetMap Carto is
| used in the OpenStreetMap documentation greatly accelerated
| our styling process (e.g.
| https://wiki.openstreetmap.org/wiki/Map_features). That
| being said, it is a loose port, and I hope we will soon be
| able to provide other derivatives, such as a positron
| style.
| placesalt wrote:
| Are coordinates stored in Web Mercator?
| bchapuis wrote:
| Yes, as the tiles are created directly from Postgis,
| reprojecting the coordinates would take too much time.
| ris wrote:
| Dear lord why would you use GeoServer for anything in 2023
___________________________________________________________________
(page generated 2023-05-28 23:00 UTC)