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)

Can you explain why these are redundant? The overhead sign indicating which lanes diverge and their destinations is a bit before the railroad bridge rather than right up at the divergence, and it was my impression that navigation would expect destination lane references corresponding to the sign

Hi- I realize I forgot to update the placement tag here, but can you explain why you intend for the way to be aligned to the shoulder instead of the centerline? It's not clear to me as that isn't where traffic generally flows.

Reverted this changeset in whole because it has nonsensical data in a nonsensical place and also messed up a church geometry. It's not a hospital, the listed address is nowhere near the POI position (which itself is in a seemingly random spot without a business).

changeset/176080554

Is this flock supposed to be inside that housing complex where you put the point or is it closer and aimed at the frontage road?

I can go double check too and look for more flocks in melissa later this week

Hello! Thank you for adding sidewalks around richardson! I see you requested review of these edits. When you add sidewalks in the future, if the sidewalk continues on the other side of any streets or parking entrances, try to continue the way across rather than breaking it into discontinuous segments. Also, try to connect sidewalks and footpaths to other sidewalks and footpaths. In the iD editor, if you draw the way across a road, it will prompt you to add a crossing at that point. If you can't fill in the exact details of the crossing, that's perfectly fine as someone who comes around with StreetComplete can do that later, so long as one exists on the map. Of course, this is texas so there are cases where isolated paths and randomly terminating sidewalks exist, but generally speaking any `highway=` should be routable to from another `highway=` on the map. Basically think of it as a tree hierarchy. I've fixed these ones at sherman street so just keep it in mind in the future.

Thanks again for editing and thank you for adding trails!

That does make me wonder if there even is any official basis for "OKC Ring" at all, since all I find calling it that are sources deliberately avoiding its more colloquial name lol
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/174922165

Changeset comment should be "add streams, adjust road alignment, draw houses, fix validator issues"