OpenStreetMap logo OpenStreetMap

Changeset When Comment
115067636 about 4 years ago

Hello,
So, you surveyed the area today, didn’t you? In that case, did you happen to find the names of the buildings, because some of them are missing. This one is building E, right?
Thanks for replying.

115053434 about 4 years ago

Hello,

Once you set highway=footway, it grants access to pedestrians and disallows cyclists. Nothing more to do.

Adding foot=yes and bicycle=no is not necessary. (On the contrary, it clutters the database.)

114890812 about 4 years ago

Hello,
Thanks for spotting this. I am sorry, I didn't expect they would have done that. I hope we’ll soon have more recent aerial imagery because there are more and more outdated places waiting for fixes. I undid the change.
Have a nice day.

114403528 about 4 years ago

Hello.

Here is an example:

In the changeset you split way/39626540, named Sint-Jansbergsdreef, into two parts because you wanted to add maxspeed to only one part of the former way. That generated two namely smaller ways: way/39626540 (same id but shorter) and way/1007645773 (new).
No problem with that, so far.

But way/39626540 was part of several bus route relations.

Here is one of them:
relation/2950645/history

This is a southbound relation, and when splitting, the order of ways within the relations should have been: 39627638-39626540-1007645773-44442738.
That is what JOSM would have done.
On the contrary, the iD editor is often confused when splitting roads and it ordered them this way: 39627638-1007645773-39626540-44442738.
That created a gap in the route. People will not see it immediately because all the segments are there and iD seems happy with it, just like an alphabet spelt as A-C-B-D.

This was fixed by changeset/114889809

I guess it’s not *your* fault. It looks like a bug in iD, despite it seems that people can have iD work more or less correctly by downloading a larger area before splitting roads.

We are running apps that rely on OSM data and our apps are broken several times a week because of newbies doing incorrect stuff with the iD editor. I see you are not a newbie and you are doing professional edits in OSM for Mapbox, hence the hope of achieving higher quality standards. We love the good work Mapbox is doing. ;-)

Have a nice day.

114732591 about 4 years ago

Hello @zazablue,

Thanks for this.

Here are a few hints to make your next contributions better.

1) We write phone numbers in the international format (E.123), i.e. +32 2 375 77 14, because that works with every phone, even from within Belgium. Do not insert a (0) in the middle, because that would break it.

2) Brussels is a bilingual city. If you write the street name on a POI, always copy the bilingual version, not just the French one.

3) If you add a point inside a building, and if the building already has an address, you do not have to repeat the address for the point itself, OSM searches will always find it. A good time-saver. (And it makes maintenance easier.)

Happy mapping. ;-)

110141684 about 4 years ago

Hello,

I hope this major change was discussed with the community. I couldn’t find a topic about it, perhaps I missed that.

This would make the Charleroi network stand out completely away from all other Belgian networks.

For instance, the ÖPNVKarte layer will render those lines in a different colour from their counterparts in Brussels, Oostende and other cities.

Even the Belgian coast tram which looks closer to Light Rail is merely "route=tram" in OSM.

Best regards.

113861126 about 4 years ago

Hello,
I am afraid this edit broke 11 bus route relations at once. The iD editor is nice to add or edit single POIs to the map, but it sucks and corrupts data for virtually everything else.
If you want to split roads, always make sure you download a large-enough territory, or check route relations manually before uploading.
Thanks.

Fixed by changeset/114890083

114403528 about 4 years ago

Hello,
Thanks for this.
Shouldn’t you consider using a better editor than iD to perform such tasks?
Splitting ways that contain route relations in iD causes a lot of undesired side-effects, and your changeset broke all bus relations here.
Thanks in advance.

114524905 about 4 years ago

Hello @Mizuna,

Your changeset description says "schoolstreet" but the tags you added are "cyclestreet".

Those are two very different things: as you know, school streets are barred to motor vehicles during school days. On the contrary, a cycle street remains open to traffic at all times but the signs imply a 30-kph speed regime and motor vehicles may not overtake cyclists.

What was the result of your survey here?

114406893 about 4 years ago

OK, thanks

114406893 about 4 years ago

Hello,

Just a question about this changeset which you titled "Added more info" without explaining what you did exactly.

Among other changes, you added a tag to this square: "start_date=2002".

This tag is ambiguous. What does it refer to? Is that the date since this place qualifies as a square? Or its name? Something else?

Thanks in advance.

114321752 about 4 years ago

Hello,

The brewery is only this building, right? way/35994932

This area here is triggering lots of validation issues.
way/1006957875

A landuse area should not have an address or contact details. Landuse is mostly used as a portion of territory.

industrial=brewery is a deprecated tag, please do not use it. (As always, tags in OSM are what we use to build the database; never rely on iD presets, they is a lot of crap there.)

type=multipolygon should only be used on a multipolygon (a MP is a special type of relation), not on an ordinary area.

113100396 about 4 years ago

Hello,
Why did you delete "network" and "operator" tags on several bus stops in this area?
We use those all over Belgium, several apps rely on this information for queries and removing them was never discussed within the community.
Any thoughts?

113859984 about 4 years ago

Hello,
If you split ways in the iD editor, do not forget to manually reorder the bus route relations. The 5 relations were broken by your edit.
I fixed this.
Happy mapping.

113985021 about 4 years ago

Hello,

Thanks for editing the map.
I think there were a few problems with the way you handled bus stops and stop position nodes here. Perhaps it would be adviseable to avoid touching those objects in the future, because they are part of a complicated tagging scheme with several interconnections.
Have a nice day.

Fixed by changeset/114020270

111993731 about 4 years ago

Hello,
I reverted part of your change.
On the roundabout there are small bicycle logos all along. This is what we call "shared lane" in OSM. I restored the proper value.
If you are unsure, you can ignore bicycle-related questions in StreetComplete or turn them off completely (Settings > Quest selection).
Have a nice day.

113597321 about 4 years ago

Hello again,
Thanks for your recent edits. The information is relevant and you seem to use the tags quite well.
Just one minor thing: tags and values are usually written in lower case, e.g. the type of food they serve. Therefore not "cuisine=International" but "cuisine=international".
I fixed this one.

113539065 about 4 years ago

Thanks but just a small tagging point here:
"highway=construction" must *always* be used along with construction=* (cycleway, residential, path…)

highway=construction

Happy mapping. :-)

113578632 about 4 years ago

Hello,

Thanks for adding more businesses to OSM and sharing your knowledge.

We saw you mentioned "Google" as part of the source you use to bring data to OSM in your last edits.

If you mean that you use their search engine to look up the website of a business, and then use the data from the business’s website, that is generally fine.

However, as you probably know, we _never_ copy data from Google Maps or Google Street View into OSM, that is illegal.
osm.wiki/FAQ#Why_don.27t_you_just_use_Google_Maps.2Fwhoever_for_your_data.3F

Happy mapping! :-)

113521350 about 4 years ago

Hello,

AFAIK the sculpture is a circular item around a tree, not the tree itself.

In OSM, we try to follow the "One feature, one OSM element"-principle wherever possible.
Otherwise we get all sorts of silly results from queries (it qualifies as a tree with a name tag, or having historic=memorial on the same node as a tree will make it appear on the same rank as other notable trees on the planet, height=5 applies to the tree but not the sculpture…).

I recommend undoing this change and restoring the previous object.

What do you think?