All the best Eden!

I hope you stay involved in the HOT community and we can keep in touch 😄

I’m always available to help with coding questions you may have!

(I forgot a line break between the sentence and bullet points and can’t update the comment, here is the nicely formatted list)

The workflow would be:

• Get survey data out of ODK along with geolocation.
• Map each survey question to an OSM tag (this is mostly handled automatically by using good XLSForm field names).
• Conflate the generated data with the existing OSM data (i.e. check if we should update existing tags, or add new tags).
• Upload the updated tag information to OSM.

You raise a great point that I forgot to include the section on how this relates to OSM - I updated!

For your questions: - FMTM currently has the default baselayer set to Mapbox Outdoors, which does of course use OSM as one of it’s sources. The attribution is present when selecting OSM as the basemap, but you are right we should probably also add the attribution to the Mapbox layer too - thanks!

• MBTiles are Mapbox Vector Tiles a format for storing multiple map tiles inside a single file. They are primarily used for displaying map tiles (basemaps) in offline settings. In our context, they can be loaded into ODK Collect as a basemap for use during offline mapping.
• Updating OpenStreetMap with tags from field mapping is definitely the plan! The workflow will be built inside FMTM, with the final stage being conflation of our data with existing OSM data (in part using our conflation code).

The workflow would be: - Get survey data out of ODK along with geolocation. - Map each survey question to an OSM tag (this is mostly handled automatically by using good XLSForm field names). - Conflate the generated data with the existing OSM data (i.e. check if we should update existing tags, or add new tags). - Upload the updated tag information to OSM.

I ended up writing the reverse query: flatgeobuf –> GeoJSON FeatureCollection. It was slightly more complex that the previous.

There are two steps required. - First a table must be created with fields representing the field types in the flatgeobuf. - Then the data is extracted from the file, using the table type as reference.

This wasn’t very intuitive to me & the PostGIS docs are really lacking here, so I hope this helps someone!

async def flatgeobuf_to_geojson( db: Session, flatgeobuf: bytes ) -> Optional[geojson.FeatureCollection]: “"”Converts FlatGeobuf data to GeoJSON.

Args:
    db (Session): SQLAlchemy db session.
    flatgeobuf (bytes): FlatGeobuf data in bytes format.

Returns:
    geojson.FeatureCollection: A FeatureCollection object.
"""
sql = text(
    """
    DROP TABLE IF EXISTS public.temp_fgb CASCADE;

    SELECT ST_FromFlatGeobufToTable('public', 'temp_fgb', :fgb_bytes);

    SELECT jsonb_build_object(
        'type', 'FeatureCollection',
        'features', jsonb_agg(feature)
    ) AS feature_collection
    FROM (
        SELECT jsonb_build_object(
            'type', 'Feature',
            'geometry', ST_AsGeoJSON(fgb_data.geom)::jsonb,
            'properties', fgb_data.properties::jsonb
        ) AS feature
        FROM (
        SELECT *,
            NULL as properties
            FROM ST_FromFlatGeobuf(null::temp_fgb, :fgb_bytes)
        ) AS fgb_data
    ) AS features;
"""
)

try:
    result = db.execute(sql, {"fgb_bytes": flatgeobuf})
    feature_collection = result.first()
except ProgrammingError as e:
    log.error(e)
    log.error(
        "Attempted flatgeobuf --> geojson conversion, but duplicate column found"
    )
    return None

if feature_collection:
    return geojson.loads(json.dumps(feature_collection[0]))

return None

Ah, I didn’t realise it was kramdown, different to fenced blocks in markdown.

I will update it 👍

That would be fantastic if you are able to contribute in either docs or code @mahjabin08!

Thank you for the offer 🙏

For code there are two routes: - Check the current issues on GitHub and leave a comment that you would like to work on something. We can have a discussion for how in the issue. - Join the HOTOSM Slack community & send me a message.

For docs, as Rob said having more usage guides and FAQs for mappers and managers would be great.

The best way to write those would be to give FMTM a go! Then write down the steps / any issues you faced =)

In general, all of the docs in the repo could do with proof reading and validating too. Thanks again!

Thank you Pradip! Excited to see FMTM taking shape - it’s moved from a prototype to a usable tool very quickly!

Great feedback, thank you! The underlying code actually supports this, so making it configurable by the user should be easy enough 😄

Also, to further reduce your costs, you can follow the guide to deploy behind a CDN for better tile caching: https://protomaps.com/docs/cdn

Pretty much! Although the main cost reduction is in the number of requests that need to be made.

Imagine you store your tiles in a typical directory structure of a TMS / XYZ server. Each tile is an individual file, and a cost is incurred when requesting each tile.

If you store all the files in a neatly packaged single file (PMTiles), then your costs reduce significantly. Only a couple of requests are made:

• The file is queried for metadata to find which range of bytes you need (i.e. which tiles).
• Then you download only the specific tiles you need to display, in a single RANGE request.

(I may have oversimplied slightly, but that’s pretty much the concept).

Thanks for reading!