You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
some polygons are successfully translated to a tagged relation of untagged ways, but others are rendered as several tagged lines. I have extracted an example of each: Yosemite National Park is correctly rendered, but Sequoia National Park comes out as three tagged lines. Each of the three ends with a point that begins another, like they should in a multipolygon.
I have tried with GDAL 2.4.0 and 3.1.4 and with python 3.7 and 3.9 with the same results. If the problem is with the data, I haven't found it. Yosemite and Sequoia look like the same sort of objects in the shapefile dbf. I don't know how to read shp directly, but I've attached a GML version with the geometry edited out and they look the same there.
sequioa-yosemite.{shp,shx,dbf,prj} -- shapefile of just these two features extracted from NPS.shp
sequoia-yosemite.nogeom.gml -- GML version of the sequoia-yosemite.shp with the geometry edited out.
nps_boundary.py -- my translation script
sequoia-yosemite.osm -- the output from "ogr2osm.py --positive-id -t nps_boundary.py -o sequoia-yosemite.osm sequoia-yosemite.shp
Thank very much for any help!
The text was updated successfully, but these errors were encountered:
In the input to ogr2osm, Sequoia National Park is a polygon outlined by a single long path. In this case, the function "parsePolygon" does not put that single path into any relation but adds it to the list of paths to possibly split into segments.
With --split-ways at its default of 1800 nodes, the function "splitLongWays" divides this path into three segments, each inheriting the tags created using the translation file on the attributes in the source.
Because the original path was not put into any relation, the function "mergeIntoNewRelation" is called to create a new relation between the three newly minted segments. The problem is that that new relation does not have the tags from the original path added to its features. So mkgmap does not render the three segments as the outer boundary of a national park.
A simple repair is to take the tags from the first of the new segments and add them to the new relation when it is created. I have a attached a two line patch that does this.
I am trying to make garmin maps for my own use incorporating the park boundaries in
NPS_-_Land_Resources_Division_Boundary_and_Tract_Data_Service-shp.zip,
which can be downloaded at
https://www.nps.gov/subjects/gisandmapping/tools-and-data.htm. For brevity, call the unzipped shapefile "NPS.shp".
This is a single layer shapefile of polygons of national park boundaries (WGS 84 with coordinates in meters, aka, "metres"). Converting to osm with
ogr2osm.py --positive-id -t nps_boundary.py -o nps.osm NPS.shp
some polygons are successfully translated to a tagged relation of untagged ways, but others are rendered as several tagged lines. I have extracted an example of each: Yosemite National Park is correctly rendered, but Sequoia National Park comes out as three tagged lines. Each of the three ends with a point that begins another, like they should in a multipolygon.
I have tried with GDAL 2.4.0 and 3.1.4 and with python 3.7 and 3.9 with the same results. If the problem is with the data, I haven't found it. Yosemite and Sequoia look like the same sort of objects in the shapefile dbf. I don't know how to read shp directly, but I've attached a GML version with the geometry edited out and they look the same there.
I have attached in a single zipfile:
sequoia-yosemite.zip
sequioa-yosemite.{shp,shx,dbf,prj} -- shapefile of just these two features extracted from NPS.shp
sequoia-yosemite.nogeom.gml -- GML version of the sequoia-yosemite.shp with the geometry edited out.
nps_boundary.py -- my translation script
sequoia-yosemite.osm -- the output from "ogr2osm.py --positive-id -t nps_boundary.py -o sequoia-yosemite.osm sequoia-yosemite.shp
Thank very much for any help!
The text was updated successfully, but these errors were encountered: