OpenStreetMap logo OpenStreetMap

Changeset When Comment
125404283 over 3 years ago

If the house is not connected to any others (as most are here) it is preferable to use building=detached. Notice that there are tens of thousands of building=detached in Ada County. Still, building=house isn't wrong, it's just not as informative.

125317883 over 3 years ago

It's Grosbeak, according to the county assessor.

55086222 over 3 years ago

Please expand the road suffixes fully. It is standard practice on OpenStreetMap because it is easier to shorten them than to lengthen them, like when they are ambiguous.

124666513 over 3 years ago

That should not happen. Red errors usually only appear for untagged features (not just no name, but nothing to indicate what it is). If it happens again, it would be great if you could screenshot the issue and submit a bug report here: https://github.com/openstreetmap/iD/issues

125373326 over 3 years ago

There is no bridge here. If you look at aerial imagery you can see a culvert. It seems like this edit was just an attempt to suppress an error rather than correct the data.

125294262 over 3 years ago

Places on military bases are usually tagged access=no, not access=private. Essentially indicates the difference between "sued by private citizen/corporation for trespassing" vs "arrested/shot by government for trespassing".

124655329 over 3 years ago

I don't support adding Bing buildings without prior proper editing or a commitment to systematically reviewing the buildings to improve their accuracy, or intent to conflate them with another dataset. Unmodified Bing footprints in the dataset don't really benefit people that much. If someone really needed them, they could just download the Bing data and the OSM data and combine them in their own database. I am dubious that the footprints are so accurate that you can evaluate so many so quickly and make accurate judgments. I am familiar with Bing footprint quality and it is very much a shot in the dark. Still, my opinion doesn't matter until a discussion is had on the import, but this never occurred. And there's the issue.

125285992 over 3 years ago

"Bldg #" does not belong in the name tag. You should add the tag ref=* and set it to the building number, and delete the name entirely, because it is not a name but just a numerical referrer. Hope this helps.

125266303 over 3 years ago

There is no sense in giving feedback to these mappers. They always have just one changeset adding their business with unrecognized tags. It is likely an SEO service that is abusing OSM but remaining undetected by using different accounts for every edit. That is my only explanation for why all of the edits look exactly like this.

124655329 over 3 years ago

That is not an import documentation page. You did not use RapiD for this changeset, but furthermore the very top of the page states: "
Adding buildings or roads or any other objects through RapiD without properly reviewing every single one is considered an import and therefore must follow the import guidelines." The fact that that entire group of buildings is inaccurate suggests that they were not manually reviewed. No one accused you of not reviewing *anything*. That is a strawman.

And if you reviewed over 130,000 buildings in two hours, that's twenty per second. That is literally impossible. This must therefore be an import, and an undocumented one at that. It'll need to be reverted.

125229745 over 3 years ago

I presume you are already aware, but just in case: this is entirely unacceptable conduct for an OpenStreetMap user. These comments are seen by anyone for as long as OpenStreetMap exists. It seems you are projecting your own lack of sincerity onto another user and lashing out at them for it. You are making no attempt to reach a resolution to this dispute and therefore believe that others are doing the same, and commenting only to antagonize. There is more to being a good member of the OpenStreetMap community than high quality edits. If you can't respect that, you shouldn't edit. Thank you.

125205663 over 3 years ago

Reverted in changeset/125243471

124655329 over 3 years ago

Where is this import documented? In the future, it would help to link to documentation in the changeset comment or a tag.

125229745 over 3 years ago

Apologies, most of my comment was written before I knew this had been reverted. References not made with this knowledge may be disregarded.

125229745 over 3 years ago

Let me try this again. All you've said has failed to address that this is an import. Regardless of whether or not you believe the rules about imports are justified, you cannot import data without prior proper discussion. There is currently grounds for any user to revert your changeset. It is likely that the Data Working Group will do so. Before I address any of your concerns, I must remind you that you are already in the wrong.

I have specifically chosen not to revert this changeset because there is something you can do to fix it. I can rescind that offer at any time. I would be in the right to do so. It is merely secondary that your data isn't as high quality as it seems. This is not an attack on the dataset. I am suggesting that the way you mapped the other dataset onto OpenStreetMap is incorrect. It does not matter how insignificant the issues are, you should never knowingly introduce incorrect information into the database for any length of time. It is far easier to add new correct information than to notice and fix existing information.

For this reason I can only accept that you either get a proposal approved to import this data as is, or correct the data. Neither the amount of time this takes you nor how efficiently that time is spent is of any concern to anyone else. There is no requirement that you must add this data to OSM.

As another user has already reverted the changeset, I will not press you any further. I would certainly offer my input if you decided to start the process of properly importing the data. Know that I will raise the same concerns I have here, and just stating that you disagree with them and with other opposing comments will result in your import being rejected.

122976149 over 3 years ago

Please do not write "unknown" for names you do not know. You can leave the name blank or use fixme=*. Also, you should not classify random segments of roads as primary_link.

125229745 over 3 years ago

That is inappropriate. The rules are clear. If you aren't manually reviewing all the data then it's an import and needs to be discussed. If it's not an import, you should be adding it with a different account.

Calling the standards that have been worked on for years nonsense just because they inconvenience you is just rude. By discussing imports, they can be made higher quality. If this were discussed and I'd participated in the discussion, I could've mentioned that there seem to be issues with some of the station names. Then you could've fixed that and had no issues with this import. Instead, you've left yourself open to someone reverting your changes and potentially being blocked from editing.

Just because you believe yourself the only real contributor of this type of data does not mean that your opinion holds all the weight.

I would rather the data be fixed than reverted. I see no reason to bring this to the DWG unless you cannot/are not willing to do so. Please: make sure no stations are duplicated (it's fine not to merge with polygons just tagged with landuse); remove state names from plant names (unless they are truly part of the name); remove refs from names (add as ref=* instead); remove website tags that don't link to the official page for an individual feature; fix website tags that redirect (I saw one in the nodes I checked).

If you correct all this, it is as though this were never an import. Otherwise, I believe the data quality will be deleterious to OpenStreetMap.

125166853 over 3 years ago

You don't need to add access tags to everything. It is obvious that cars aren't allowed on paths and as there are no signs actually posted about horses, no need to add that either.

125039371 over 3 years ago

Apologies for the error. I likely misclicked when trying to select an address node.

124940048 over 3 years ago

Fixed in changeset/124960335