Thank you, that does appear to resolve the error correctly.

Oh no! I didn't realize this happened, working in ID editor and thought it split near Brokaw Nature Area since highlighting doesn't load unless you zoom out. Would love help in correctly splitting the river area to demarcate the transition from reservoir to river as separate namable shapes.

Great job overall, but the trampoline park tag doesn't seem to be the right application for a single trampoline in a backyard. I'm not sure there is an existing tag for a single trampoline in a backyard like there is for a swimming pool.

Fixed GNIS and Wikidata association in changeset: changeset/97468776

Interesting and great find, the GNIS manager checked and said the compiler identified the wrong lake and updated the coordinates, but didn't state what information was used to verify the coordinate. The GNIS ID was created 14-Apr-1980 so its probable the larger lake is the correct, but I'm asking for clarification on what data they used to update. I wish GNIS ID pages had a history or changelog. There are two coords listed now from two map sources now, once I hear back I'll update the GNIS ID tag and Wikidata respectfully of the correction.

To clarify I mean get the GNIS coordinates updated for the associated name.

I'm thinking you might be right though the GNIS coordinates land within this body of water. I agree the USGS topo map is unclear. It could be that when the land was developed a larger body of water was split/drained. I'll reach out to Michigan GIS which supplies the USGS and the USGS manager to see if we can get this clarified and the data updated if this is the case.

To clarify I've only checked Michigan lakes in Wikidata to GNIS.

Hi Max,

GNIS is comprised of the named features provided by the state to the federal government thus if it exists there we should treat it as present and if we can disprove it should be reported to the state and USGS to be marked historical. If it is not marked historical there is an indication it should exist at the reported coordinates. There are only a handful of cases in Michigan (I went through all manually) that the need to split or be discussed if they still exist. This is one of those cases. I've reported a handful of data errors already for verification and they were corrected in GNIS especially in cases of duplication. That said we should be cautious about dismissing GNIS outright as it is the authoritative record of named places in the USA. I'm ok with questioning wikidata entries, but I've manually verified all those with GNIS references in wikidata and imported those missing so they can be build for linked data.

If you look at the GNIS entry referenced (https://geonames.usgs.gov/apex/f?p=138:3:::NO:3:P3_FID,P3_TITLE:627197,Grass%20Lake) the coordinates are 44.2366928, -84.0565571 which land squarely in the body of water currently labeled Lake Ogemaw, but not with a clear division. Named features don't necessarily need a hard division to have a different name and the polygon should reflect this. On the USGS topo layer the larger body of water is labeled 792 which also indicates there should be a section of land which means the map is out of date from the physical feature, but does not mean the name is not applicable to the section of water.

I think the appropriate action here is to contact the state of Michigan regarding the feature and if they verify it no longer is recognised and will be updating GNIS then we should treat it as historic.

I haven't had the time to go back to these yet and dig in so thanks for giving it a kick. Ideally there would be a check against any GNIS tagged feature changes each month since there is some changes and corrections made as the data is found to be stale.

The reference of the sounding is primarily for fishing lakes and is not comprehensive so I wouldn't use that for an authoritative comparison. I've emailed a few times with MI GIS and they are responsive, but it could take some time. They are aware of my work so far and one thing I've been meeting to look at is their open data and compare that to their GNIS to see how well data handoff is going from state to national and back.

So I'm happy to discuss this further and would love feedback. I've been trying to take a systematic approach to data quality for lakes in MI as I'm looking at this as potentially part of a case in my PhD dissertation... so I'm focusing on quality checks as I go.

Regards,
Jonathan

Hi Jesspher,
Thanks for asking. I only linked the water since the GNIS entry which I imported to Wikidata only refers to the water itself as it is class lake of named places as I've applied to most lakes in Michigan now. The wetland which appears to be mistagged as water and I've corrected to wetland does not appear in the GNIS database under the Swamp label thus would have a different Wikidata entry and GNIS ID. The wetland name is not verifiable based on information presented so I've removed the Dog Lake name from that multipolygon. The two shapes are not in a combined multipoloygon or relation thus should be treated separately.
I hope this clarified the issue and thanks for catching this oversight. :)
Cheers,
Jonathan

What is the source for the name Piccolo Lake? USGS Topo layer and GNIS 2106608 both state this is Crystal Lake and GNIS does not list the Piccolo Lake as an alternative name.

The larger area appears to be wetlands primarily while adjacent to the golf course. The existing water area is officially Kellogg Lake according to GNIS and the USGS Topo layer. I left the water_hazard tag, but added the wetlands tag.

Hello! Again, I do add shapes when there is suitable resolution in aerial imagery for high confidence in the borders of park boundaries. I would rather not add boundaries without confidence in their representation on the ground. A POI is better than not existing, but I agree a shape would be preferred.

Hello! I do add shapes when there is suitable resolution in aerial imagery for high confidence in the borders of park boundaries. I would rather not add boundaries without confidence in their representation on the ground. A POI is better than not existing, but I agree a shape would be preferred.

Hi Rene,

I'm actually already using https://wiki.openstreetmap.orgdata.link in my process for this, but between the objects I'm looking at never having a candidate match and the UI for when candidates are suggested isn't clear on the object I've opted to open OSM to edit manually until it is improved. Happy to detail further in a message, haven't filed an issue to outline the issue nor suggested corrections for this experience yet.

Cheers, Jonathan

Thank you for the assist, I did not have time to get back to this until later Friday (tonight). I will check to make sure none of my error remains and will read up on this issue as well as refine my editing process for unfamiliar practices to avoid this mistake in the future. :)

Thank you for pointing me to this reference as I was following the ID editor's QA tool suggestions. I'm reading more of the SE transit tagging and will work to revert the removals of highway=platform which I applied. My apologies for the mistake, though I do see there is active discussion on rendering of these via https://github.com/gravitystorm/openstreetmap-carto/issues/311

Added as issue https://github.com/openstreetmap/iD/issues/3929

Ah, I think I know what the issue is. I've noticed if the wikipedia field was present for an item without selecting the dropdown and you edit the wikidata field is not queried and added. Actually there is a broader issue with this issue too, at least there was from what I observed in my last wikipedia linking sprint. Items which already have a wikipedia entry do not also have a wikidata entry and to correct one must delete the wikipedia field then add again for the wikidata field to be automatically added. Might be worth verifying and reporting that or looking into why that is occurring since it does cause a data completeness issues like this missing the wikidata entry.

Yes, I'm using the dropdown wikipedia field to get the wikidata association as well.