That is great news that it is official. Thanks!

Thanks for all the comments!

@Zverik - The vast majority of imports (probably over 95%) are detectable. However, a knowledgeable person that wishes to make the import hard to detect certainly can. Obliviously, it is impossible to know how often this happens.

@Stereo - I agree that the fact that the term isn’t clearly defined is interesting.

@DevonshireBoy42 - I have no plans on what to do with the detector and we will see if it goes anywhere useful.

@Glassman - Pulling road names from Tiger is a kind of import, but it doesn’t need to follow the import guidelines we all know that it is OK because Tiger is public domain. However, pulling road names from google, isn’t ok. For small imports we skip the import guidelines and deal with them by reverting them after the fact if they have problems.

Finally, the word “directly” would exclude tracing over an image layer.

Hi Thanks for commenting.

• I fixed the SOTM. Thanks for pointing that out.

I don’t see any reason why the servers would need to move. OSMF would still be a non-profit, the money would be used to support the project, and we would simply be asking for donations for heavy tiles or Nominatim use.

The foundation needs to have money to purchase computers, bandwidth, electricity, (and most importantly) system system administrators. The vibrant commercial space that is downstream validates the tremendous value that is inherent to our data. I don’t see any reason that we should not be capturing some of that value to self fund the project. Selling services would also avoid the conflict of interest problems we currently have with pure donations model. It seems really simple to me.

@roym, my post clearly explains why Mapbox and Microsoft can’t put the sat images into BitTorrent. Also, Facebook has released the AI part of the road detection code here https://github.com/facebookresearch/Detectron. Nothing is stopping you from getting involved.

On the Facebook road import, as someone who works on this kind of stuff, the code they wrote is really not that interesting. What we (OSM) should of asked for is the hand drawn training images. They are the most valuable part of what Facebook created. Looking at the training images and noting how many they had would of given the community a pretty good idea on how well the final data was going to eventually look.

@daniel_solow, no worries. I did it myself a couple of times.

Thanks for reading the post. I just made another pass at the wiki

https://wiki.openstreetmap.org/wiki/Tag:sport%3Dbaseball

Fun read, thanks!

Wow, you are cranking through them!

👍

Perhaps somebody could work out a procedure for quickly making relations from existing ref tags?

Hi Alan, The landuse=forest, leisure=recreation_ground, landuse=recreation_ground were missing, or on the wrong places, etc. I think they are correct now for Groton at least….

You can revert bad imports without the DWG.

The situation with highway=path, highway=footway is very annoying. Regardless of what the wiki says, in practice there is no difference between them. I would support recognizing reality and rendering them the same and render based on common sub tags like surface, access, etc.

SK53 I have yet to see any evidence that imports discourage real mapping. If you mapped locally, you would know that the playground you pointed out as being off was from the open space import in 2009, and not from the L3 parcel database, which is quite accurate. Measuring map quality from POI’s in MA is a very narrow evaluation criteria. Again, if you were local, you would know that many mappers in MA are outdoor enthusiasts, our hiking and biking trail network in the state is hands down the best and most complete source available.

Change the style based on highway= node density for the current tile.

External consumers should store the id’s of the OSM objects and process the changeset files to keep the ids up to date, tracking when the move, deleted, added, turned into area, area turning into a relation, etc.

We are around 35% the size of Wikipedia in active monthly contributors.

https://stats.wikimedia.org/EN/TablesWikipediaZZ.htm

If you are looking for ideas on fixing it, you could write a python script takes an OSM file as input, and uses Shapely to chop up the relation into a bunch of smaller relations, outputting an OSC file. It would probably be ~ 25 hours of work.

Land use imports should be broken up into smaller relations when they uploaded. If you are handy with software, you might be able to pull it out, break up, delete the old data, then re-import it. You could also propose just deleting the entire thing. we should not be afraid of deleting imported data that is causing problems. You can decided what you think is best, then post an email to your local mailing lists, and see what people think.

If the people on the board can’t stand being in the same room with other and don’t trust each other enough to share the check book register and the membership list, the organization is the least of the problems. Hopefully the chemistry of the board members improves, otherwise, a reorganization would be rearranging the deck chairs on the Titanic. Fortunately, the project marches on in spite of the dysfunctional/unhappy board.

We should allow everybody with an OSM account to vote for the board, so this process is not dominated by the top 0.0001% project.