maxerickson's Comments
Changeset | When | Comment |
---|---|---|
49305450 | about 8 years ago | Hi- This looks like is should be tagged shop=furniture. You appear to have stuffed SEO in the "amenity=" tag. Don't do that, use correct, well established values. Also, please review the formatting of the opening_hours tag. Last, there is no need to repeat name in loc_name if they are the same. Thanks, Max |
40941493 | about 8 years ago | This edit made the node a semi-duplicate of osm.org/node/153532049 which is ~1200 meters to the west. It's likely enough that "New Town" no longer means anything, but there is a nearby church using it as part of a name: osm.org/node/1567956649 also the cemetery just to the east. In general, I think the gnis place nodes need to either be deleted or have the place=hamlet modified to something better, the names seem to be pretty reasonable (at least, they were in use at some point). I think in this case it would take local knowledge to determine if New Town is a neighborhood in Spring Hill or not. Max |
47887496 | about 8 years ago | Hi- I just wanted to explain why I've deleted your walking paths from Oak Hill Cemetery in Griffin. The way the OpenStreetMap data model works, a road like an access road in a cemetery, which is open to both vehicle traffic and pedestrians, is entered as a vehicle service road (and then maybe some extra information about whether a pedestrian can use it; in the US most such roads are open to pedestrians and don't really need the extra notes). It's totally fine to add features that make PokemonGo more fun. But please do take the time to make sure that they fit in well with the other data and that they follow general OpenStreetMap practices. As a style note, roads shouldn't overlap each other, and it is better to add multiple individual pieces than to double back and things like that. Thanks, Max |
46646942 | about 8 years ago | Hi- Could you reconsider using tags like amenity on features that you give a (Historical) name? For display purposes it isn't important, but for things like a search or statistics, the fact that the feature is historical is buried in the name and without special handling will end up showing bad information. An example in this changeset is "Baldwin County Courthouse (Historical)". Adding the building and somehow noting the old name makes good sense to me, but if it isn't used as a courthouse anymore then it shouldn't have the amenity=courthouse tag. One way people handle it is to use a "was:" prefix on the key, so like "was:amenity=courthouse". For things like demolished schools and similar, I'd suggest deleting the node (many are present because of an imported dataset (GNIS), so someone interested in the information can still easily get it from there). Thanks, Max |
46713441 | over 8 years ago | The tweet you have linked as a source clearly indicates the consulate on Gießener Str., which has already been mapped as an area: osm.org/way/5053010 So I'm not questioning whether the consulate has been identified in the tweet, I'm insisting that you've incorrectly located it when you added it to OSM. Anyway, I've deleted the node in osm.org/changeset/46829509 If you still want to document the information from Wikileaks, I'd suggest adding it to the already mapped consulate. |
46713441 | over 8 years ago | Hi niubii, can you please at least fix the location here? The spot you have marked is in a cemetery, it's not the US consulate. Thanks. |
46713441 | over 8 years ago | The location is still incorrect... These buildings are part of the cemetery. The US Consulate is just to the east of the cemetery. I don't know if Wikileaks is correct or not, it's just that such speculations aren't really the type of data that is stored in OSM. That there is a US government facility is clearly suitable for OSM. Speculations about the activities carried out at the facility are less so. |
46713441 | over 8 years ago | This is not the location of the US Consulate in Frankfurt. Fortunately, the correct location has already been mapped: osm.org/way/5053010#map=17/50.14093/8.69576 Please delete this incorrect location and consider not adding wikileaks speculations to OSM, people looking to find the US Consulate won't have any trouble finding the correctly labeled Consulate. |
20558702 | over 8 years ago | Hi- Would you consider using religion=unification for osm.org/node/2671143837 ? Even though it is not widely used I think it is better than the incorrect value. Thanks, Max
|
38253260 | over 8 years ago | Hamburg. Like I say, i went ahead and made the changes I described: |
38253260 | over 8 years ago | Hi- The gnis attributes you added (from node 153435830 ) to the town correspond to a different entity than the town. The town is 1583338 (It may not have been imported into osm, I haven't checked carefully). 1581839 is the named, unincorporated, populated place that exists inside the town. There's a similar issue with the wikipedia/wikidata links, but those existed on the village node (I came across the issue at https://www.mediawiki.org/wiki/User:Yurik/OSM_disambigs ). I think it isn't a terribly big problem, but it is probably worth being consistent with the other datasets. I've adjusted the objects to match what I describe above (restoring the hamlet) but I'm open to discussion if this is the correct/best way to model the situation. Max |
45382068 | over 8 years ago | Hi- The tag "access=yes" on this footway: Doesn't really mean anything. The default access= state for any highway is yes. horse=no and motor_vehicle=no are also quite redundant on a way tagged highway=cycleway/footway/path (as the widespread default assumption is that they are both no for those types). There is no need to add them. Another problematic combination of tags is highway=cycleway and cycleway=track. cycleway=track is meant to indicate that there is a separated cycle track associated with some other way. See osm.wiki/Key:cycleway for more. Data consumers will just ignore it, but it does imply that there are 2 cycleways when it is tagged on a highway=cycleway and will be confusing to new mappers. Thanks, Max |
45065400 | over 8 years ago | I would say don't worry about it unless you go find the legal documents incorporating the town and set the boundary from that. My main concern is the structural one, I don't see merging other features into the sloppy Tiger boundaries as "cleaning up boundaries", it's mostly churn that makes it harder for naive users to edit them correctly and creates the (likely false) impression that the boundary has been improved. |
41821355 | over 8 years ago | Brief research indicates that the Brownestone Inn (osm.org/node/4376977803) added in this changeset was actually demolished more than a decade ago. What source have you used to add this hotel? Is it highly reliable about current hotels? Looking closer there are also several nodes added that partly duplicate existing features rather than enhancing them. It's better to add information to the existing feature. |
42943130 | over 8 years ago | Re the stretch along osm.org/way/233849121 , trunk vs primary is more sensibly a network distinction. A few miles of trunk doesn't make any sense. The road is overbuilt, but it should be the same class as the adjoining sections. |
45228653 | over 8 years ago | Reverted in osm.org/changeset/45231121 . |
45228754 | over 8 years ago | Hi- I've reverted this changeset in osm.org/changeset/45231012 . You should not be testing edits for opengeofiction using Openstreetmap. I came across this edit as rendering artifacts in North Carolina, so in addition to being inappropriate for OSM, there was also something strange about the data. Max Oi- Eu revertei este changeset em osm.org/changeset/45231012. Você não deve testar edições para opengeofiction usando o Openstreetmap. Eu vim através desta edição como renderização de artefatos na Carolina do Norte, por isso, além de ser inadequado para OSM, havia também algo estranho sobre os dados. Max |
45065400 | over 8 years ago | Are you researching the administrative boundaries here? I really doubt that a town ends on the centerline of one side of the Long Island Expressway. The goal should be to make the boundaries legally accurate, which will frequently conflict with merging them with convenient nearby features. |
45191235 | over 8 years ago | Right, you should definitely at least discuss this sort of editing on the imports mailing list (large scale automated edits are also subject to the import policy). It should be possible to break up the uploads into chunks that are handled more gracefully (after exporting the data from QGiS). |
45191235 | over 8 years ago | Is there some reason you are uploading so much data at the same time? Also, you appear to be doing an import. If that is the case you should read and follow the guidelines: |