Hi! The tags for these are landuse=industrial and industrial=wellsite . I've fixed the tag on this one for you, thanks for finding it :)

What did you mean by Entry=no/yes? If you're referring to whether the general public is permitted/able to go through the gate, the normal tag for it is access=private or access=yes (or access=no if it's usable by literally nobody including emergency responders)

Hello,

The tag highway=services indicates highway/motorway service stations, not features that would be present in an amusement park. Please consult the wiki for tags when you aren't sure about their intended usage. It's not immediately clear to me what you were intended to map with these. Could you please clarify?

highway=services

Furthermore, you have not been listing sources with any of your changesets. In OSM we must be able to know how users obtained the information they map (whether it be observing it personally, viewed from aerial imagery, from a particular dataset, etc). Could you please fill the Sources field in each changeset with the source of the information? source=*#How_to_use_on_changesets

Do these pathways you removed, particularly the ones around the amphitheater, still exist? They still show on all the newest aerial imagery for me. If they were recently demolished, it would be better to use `demolished:highway` on a temporary basis until some aerials are updated, so that other editors don't get confused, and to put `landuse=construction` around the area of construction. If they do still exist on the ground but are just not accessible, they should be left but tagged with `access=private` or `access=no`. I'm just a little confused by how many still-visible-on-aerial roads and paths are now gone from the map.

By the way, do you know the current status of the Six Flags Railway? I see that goes through an area that looks to be under construction.

Hello! Please see this site for the list of standard tags that ALPRs need to have to be recognized by apps like deflock https://deflock.org/report/id

I'll fix this one, but specifically it should have at least

man_made=surveillance
surveillance:type=ALPR
surveillance=public
camera:type=fixed

And if known for sure that it's flock (and not say, motorola)

manufacturer=Flock Safety
manufacturer:wikidata=Q108485435

I have reverted this as there is no parking lot here. There once was, but it has been demolished, as evidenced by the newer esri imagery and the landuse=construction describing the construction project.

Just checked for myself and there really are ALPRs there. What a strange decision by Frisco lol. There were some ptz cameras along the trail too which I added the rest of I think

Thanks for helping keep track of surveillance tech. I fixed it this time, but when you add the nodes (presumably by pasting from the tags on the deflock example) you have to paste it into the raw text input for tags, rather than as the value of an individual tag. Basically, you have to click the `I` looking button at the top-right of the tags pane. See where the arrow points here https://deflock.org/report/id . This will ensure each key=value on each line is a separate tag, rather than all that text just being shoved into the value of one tag. Does that make sense? Let me know if you need further clarification

Also, what kind of cameras were those on Caddo Trail? Were they the normal ALPR-style flock cameras like on the example image on the deflock site? Or were they one of these flock ptz cameras: https://www.flocksafety.com/blog/stop-choosing-between-coverage-and-clarity-dual-lens-ptz-delivers-both

If it was one of those, two tags should be different: surveillance:type=camera` (rather than ALPR) and `camera:type=dome` (rather than fixed)

Thanks so much, and please keep adding them when you can!

CHanged to demolished:highway: changeset/181743223

I reverted this changeset because this parking lot has been fully demolished. The bing imagery you used to re-create these service roads is very outdated. As of now, this entire piece of land has been excavated.

changeset/181706867

I reverted this changeset because this parking lot has been fully demolished. The bing imagery you used to re-create these service roads is very outdated. As of now, this entire piece of land has been excavated.

changeset/181706609

Hello! I've noticed that you've added duplicates of The Lot TX 3 or 4 times. ICT_maps fixed it for you, but try to make sure you're fetching updated map data before assuming an edit didn't go through and trying again. If that wasn't the case, could you explain what you are trying to fix?

Also, minor thing, but try to format phone numbers as +1-123-456-7890

Hi! Thanks for joining and contributing. It's fixed now, but in the future try to be careful where you place nodes for new objects. This Aldi was added to a house 1/4 mile away from its actual position...

I've never used MAPS.ME so I'm not sure exactly how that happened, but try to be mindful of where it places nodes.

I'm confused too. Editing across the entire world at once (and having a world-spanning bbox) is not ideal but it doesn't look automated to me and only affects 24 items

Hello, I've fixed this because it added a duplicate highway=secondary where the ramp is supposed to go. When fixing a road with the slip ramp too far back, you should move the junction to the correct spot or recreate the highway=secondary_link rather than adding a second, parallel, duplicate one

A [Relation:boundary] is a group of one or more ways (think like how a road is drawn, but not a road) that defines the physical city limits of one or more cities. So somehow what you ended up doing was setting Keller's entire city limit line as an ALPR lol. Not sure how it happened either, but I think you can prevent it from happening by hiding city boundaries in the editor and that should prevent them from even being interactable with at all. Click on the map data icon on the right of the editor and uncheck Boundaries. If it was already off then I'm really not sure what happened lol, but don't worry too much unless it happens again.

If you find the online editor to be confusing, you could also check out JOSM. It has a lot more features and an even more complex interface, so it's definitely not for everyone, but counterintuitively I found that I have an easier time understanding what I'm doing when I use it.

You might already be aware of it, but the Deflock app is also an option for editing. It provides an interface for editing ALPR-related features only, and is pretty foolproof and hard to mess up other things with. If you also want to edit non-ALPR related stuff on the go, I recommend the app EveryDoor, it's especially good for things like adding shop details or park features.

As someone from NRH, thanks so much for joining and helping us keep track of the surveillance! If you're like me you'll end up addicted and start adding park benches and sidewalks too :)

Are there 2 flocks side by side here or was it accidental duplicate? I tried to pull my dashcam footage from the last time i drove by here but it was night so couldn't tell for sure

I guess another way to put it is, my understanding is that the usage of the placement tag is discouraged by proxy because its existence on a way implies that the way is not drawn in the center of the road (and not drawing a way in the center of the center is discouraged unless inherently necessary to represent it). Therefore, avoiding the tag by drawing even more ways that aren't in the center of the road just to not use the tag itself feels incorrect to me.

My thoughts are that the ways are supposed to be aligned to the center of the real-world object (the road) and the `placement` tag used to specify situations in which this is deviated from for some reason, in order to help renderers display positions properly. It would seem to me that your method is the opposite (i.e. mapping based on the curvature of traffic flow and then using tags to specify the real location). I looked through Proposal:Placement, and it doesn't seem to suggest to me that transition ways should be avoided at all cost; it suggests that they are to only be used when necessary, and goes on to list motorway junctions as situations in which they are inherently necessary, simply because the width of the road changes there. I take it to mean that situations in which they are not necessary would be like, moving the way across the middle of the highway for no reason. While I should have been more careful to place transition tags on all such segments, I don't really agree that drawing ways that strongly deviate from the real-world center of the object in order to avoid them on the exact thing they're intended for is a good idea... If nothing else, it seems to strongly deviate enough from how I've seen everything else mapped everywhere.

I see. I don't have any particularly strong opinions on it myself, nor do I know of an existing consensus. There didn't seem to be anything useful that I saw in the destination:lanes page. It just did seem strange to me since my assumption was that it was intended to correspond the same to turn:lanes etc (i.e. where signage or markings indicate the lane)