Proposed import of HIFLD Fire Stations n Mississippi

I’ve decided to take a slightly different approach to all of this. I’d like to approach this import on a county-by-county basis. I was having trouble determining how I would keep track of which departments had been added, which already existed, etc.

I’ve created a page on the Wiki for this effort:

https://wiki.openstreetmap.org/wiki/HIFLD_Fire_Stations_in_Mississippi

The Wiki page is not comprehensive yet, seeing as I’ve been doing this work with a broken wrist thus far :joy:

If anyone would like to analyze the layer I’ve completed for Tishomingo County, MS, here’s the link.

It seems that you have to approve my access.

Could you tell us what you have done to address the concerns with the data conversion.

My apologies, I tried to strip the excess tracking tags off of the URL, this link should work.

I’ve checked that each address contains a house number, street, city, and state. I’ve added an area around each building then placed the address, amenity=fire_station, and name on its respective area. There was one particular station that had a null house_number value so I deleted the key & value. I verified the addresses of those that had one present online.

I also added buildings tagged with building=fire_station and any obvious parking that may be at each site.

Thanks, I will take a look.

The file you shared seems to contain fire stations outside of the indicated county

Yes, my apologies, the relevant counties are those in the Northeast corner of the state.

Could you provide a file of just the data you intend to import during this first step?

Also, the file contains a name:en tag. I am not sure that is necessary.

The ele tag is probably also not needed. If it is going to be included, make sure it is in meters and not feet.

Most recent file: here. There were 4 Fire Stations already in OSM in this county.

The elevation data is confirmed in meters.

The name:en tag is not present in this file.

I suspect you still have an issue with the data conversion. The Valley Grove Volunteer Fire Department had an address in the original HIFLD data (I realize that you are now using data directly from the National Map, but I think this still applies) of “County Road 993 and County Road 86” In the latest data you provided this was changed to “Road 993 and County Road 86” (the first “County” was removed)

Also, how are you coming up with these polygons for the amenity=fire_station features? Are you copying from parcel data from the county (or other source)? Does that source have a license compatible with OSM?

Noted.

I’m tracing the area based on Bing Imagery.

Ok, that works for me. Others may have a different opinion.

Thanks, I will take a look.

That is good. However, the elevation data on point features from the USGS has to be taken with a grain of salt. At least at one time these were inferred by doing a spatial query against a rather course DEM. Perhaps that has changed.

Rest of the community: What is being proposed here is that fire stations be mapped not as buildings, but as the entire facility (the building, the parking lots, and other areas around the actual building). I haven’t generally seen this done before, although I don’t think it is per se wrong. (the buildings themselves are also being mapped separately as building=fire_station)

Huh. I could have sworn there used to be an image on the page for amenity=fire_station that suggested mapping the whole grounds as the amenity (similar to amenity=school).

It’s like amenity=fuel and other amenity=* POIs: unclear whether an area representation is better or worse. I assume very few map styles would shade in an amenity=fire_station area, so a user would perceive would perceive a label or icon potentially floating over an arbitrary location whereas it’s actually centered over the invisible area. But it technically isn’t wrong.

A fire station is usually housed in a dedicated building that you could tag as building=fire_station, but sometimes it’s located inside a city hall or even a water tower.

I have confirmed that @pb-mapping is doing this. Each amenity=fire_station representing the overall facility also has within it a closed way tagged building=fire_station. They also mapped some parking lots and other buildings within the facility. Generally looks good, just need to make sure the data conversion is done right, and there is a good process for all of the other counties (we don’t want to be reviewing every county).

There do not seem to be any cases of that in this county.

1 Like

Yeah, the guidance on the amenity=fire_station Wiki and its examples feature the grounds mapped and tagged with amenity=fire_station and buildings specifically with building=fire_station so that’s the approach I took.

If you think I should make any changes, let me know.

I understand completely. Thank you for your help!

Completed the first changeset of this project! Feel free to check it out and critique anything.

Edit: I missed an abbreviation of Highway at Holts Spur Volunteer Fire Department but fixed it in a subsequent changset. I’ll implement a better review to catch this in the future.

Thanks for the heads up.

It looks like the data conversion is still not right. Coleman Park Fire Department has an address of County Road 402 in the HIFLD data, but, in the imported data addr:street=Road 402 Whatever you are doing with regards to data conversion, you need to do something different. This is very similar to other errors I have pointed out to you before.

Speaking of HIFLD, in your changeset comments you cite one of the sources as HIFLD/Emergency. I thought you were switching to The National Map data.

Clearly, I’ll work on it. And I went ahead and fixed Coleman Park FD’s address.

After examining The National Map data and filtering for fire departments, it has one less record than the HIFLD/Emergency dataset so I used what I had already converted (being HIFLD). They are basically identical from what I’m seeing.

addr:street for the Eastport Mill Creek Fire Department does not match any nearby road that I can tell. This is an issue with the source data. The JOSM Plugin MapwithAI has a validator that will check for this.

I really appreciate you working on it. However, it is very concerning when the same type of error shows up after it has been pointed out before. In the quality control/assurance world, when an issue has been pointed out, the producer is expected to correct/improve their process to prevent similar errors from happening in the future (or at least greatly reducing the chance that they happen again). Fixing the example case cited by the group doing QC/QA isn’t enough. We want to get to a point where we don’t have to review all of your imported data county by county. We are not there yet IMHO.

Perhaps that is because that one fire department no longer exists? I don’t know, but assuming one dataset is better than another simply because it has more records doesn’t make sense. When it comes to data, more is not always better.

The conversion needed to be redone anyway.

Holts Spur Volunteer Fire Department (Way: ‪Holts Spur Volunteer Fire Department‬ (‪1414105074‬) | OpenStreetMap) seems to be part of the import, but does not seem to be part of the original HIFLD data (downloaded from HIFLD) (or the National Map Data). It also does not appear to be in OSM prior to the import. Perhaps I am missing something.

I never stated that one was better than the other simply because it has more records than the other. I stated that “I used what I had already converted (being HIFLD)”.

1 Like