search

ngageoint / hootenanny

Hootenanny conflates multiple maps into a single seamless map.
GNU General Public License v3.0
356 stars 74 forks source link

Hoot translation from FGDB to osm (node count within ways) #1362

Closed Cellington1 closed 7 years ago

Cellington1 commented 7 years ago

@mattjdnv After translating a FGDB (Rafah Dataset) to osm xml I noticed that the resulting xml had two ways that contained > 2,000 nodes. This exceeds the 2,000 node to 1 way limit set by the osm api. This is the first time I have seen this behavior. Let me know if you would like me to provide any further information.

bwitham commented 7 years ago

I don't believe hoot restricts the way node size internally by default. To do so I think you'd have to apply the SplitLongLinearWaysVisitor as a post processing op to the data.

sisskind commented 7 years ago

Based on customer requirement, it is possible to set a ceiling on it by default of 2000 nodes? @bwitham

bwitham commented 7 years ago

Yes, if you add that visitor that I mentioned above to whatever hoot command you're using, all ways should be split until they contain no more than 2k nodes. Or at least I think so...that's what the documentation indicates...I've never actually used it.

Cellington1 commented 7 years ago

I believe that this is something that would need to happen on any export to osm through the Hoot UI. I'm also wondering if this actually splits the ways into related linestrings (We are thinking that is how osm handles large Landuse features exceeding 2000 nodes) rather than multiple ways. I'll take a peek at the code when I get a chance.

bwitham commented 7 years ago

Should probably happen for anyone wishing to ultimately view the data from an OSM API db, where that limit is imposed. Not everyone will be using an API db for storage and may not wish their ways messed with on export....so it should be optional.

bwitham commented 7 years ago

This isn't a bug. A solution was outlined earlier in the thread.