piebro/osm-data huggingface dataset:
MxxCon (2026-07-06 05:28:05+00:00): Rather than source1 and source2 tags(which I don't think are valid), why not use standard source= tag and list both urls with ; ?
Also, have you seen https://www.brooklynnavyyard.org/wp-content/uploads/2026/06/Tear-Off-Map-Layout-New-Building-Numbers.pdf ?
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/185131632
eggie (2026-07-05 10:32:29+00:00): Dag Jurjen,

Je vraagt feedback.
In osm Nederland taggen we bedrijven bij op de adresnode. Niet op het gebouw.

Mvg,
eggie
JurjenH (2026-07-05 10:36:22+00:00): Hoi Eggie,

Ik heb alleen de bestaande vermelding aangepast, niet wetende dat die technisch niet correct was. Hoe nu verder?

Jurjen
eggie (2026-07-05 10:48:29+00:00): Hoi.. Het is geen ramp. Je kunt de info bij taggen op de adresnode. En dan haal je de adres- en bedrijfsinfo van de gebouwomtrek af.
Ik doe het meestal met een trucje middels kopieren naar een zelfgemaakte node. Haal alles wat niet ter zake doet eraf (Bag info en building )en combineer die met de adresnode.
Probeer maar als je zin hebt.. 

Mapse
ieguy3 (2026-07-05 10:37:03+00:00): the road follows the McLaughlin road alignment has signs saying "new traffic pattern" but i am not sure if the old portion of Mathews is going to be reopened. my understanding is McCall will eventually  reach grand. so i am not sure if Mathews between Palomar and Briggs is going to be abandon. oh they are also expanding McCall  from antelope to Junipero. the ROW just east of leon is a minimum of 4 lanes wide and under construction
gurglypipe (2026-07-05 18:54:02+00:00): Hi, thanks for updating the tagging on these. Just a note — some of them still have farmland=pasture tagging which is outdated and should be replaced with meadow=pasture. I noticed two fields in the NE of this edit, but have not checked them all.

If you could update your editing script/practices to catch those tags (like crop=grass) and update them too, that would be helpful.
SCMapper9947 (2026-07-14 07:55:43+00:00): Sorry for that, i'll pay more attention when I do that again
eggie (2026-07-05 11:01:45+00:00): 👍
pitscheplatsch (2026-07-05 11:29:06+00:00): Hi, welcome to OSM.

Could you please clarify how the added names are verifiable on the ground? Is it shown on a sign or commonly used locally as the actual name of these features?
eggie (2026-07-05 11:36:18+00:00): Lijkt me oke..
Een afrastering kun je apart intekenen met
..barrier=fence
Mapse
Marvk (2026-07-05 12:00:02+00:00): Hi klev12,

der wert für https://wiki.openstreetmap.org/wiki/Key:via_ferrata_scale passt nicht zu den "Standard-Werten" für dieses Tag, hier wäre vermutlich 1+ oder 2- zu taggen.

Beste Grüße
Marv
klev12 (2026-07-05 12:45:20+00:00): Hallo Marv,

Danke fur den Hinweis. Ich ändere es auf 2-.

Gruss
MxxCon (2026-07-06 05:36:11+00:00): Why did you add tiger:* tags to way/361078731? They are leftovers of 15-year old data import.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/185134500
Svalbard (2026-07-06 17:06:14+00:00): Hallo Peppi95, stellvertretend für Deine letzten Änderungssätze, in denen Du flächendeckend Adressen ergänzt hast, die Frage: Welche Quelle hast Du genutzt? Ich kann mir nicht vorstellen, dass Du die Daten alle vor Ort erhoben hast. Nutzt Du dazu das Geoportal SH? Ich frage, weil Du in einem Kommentar mir gegenüber schon einmal auf das Geoportal als „Quelle“ hingewiesen hast. Die Nutzung ist für OSM nicht erlaubt. Es wäre nett, wenn Du mal auf Changeset-Kommentare reagieren würdest. Gruß Svalbard
bxl-forever (2026-07-05 12:16:49+00:00): Hello,
We fixed the name because we don't believe the entire name should be entered in lower case.
gurglypipe (2026-07-05 18:52:16+00:00): Heya, did you mean to tag this as a garage? It looks a lot like a house.
AndiBing (2026-07-05 22:25:39+00:00): Emmm. Didn’t change the building type. Strange. 
Yes you are correct it is a house. Semi detached/ end terrace.
AndiBing (2026-07-05 22:44:07+00:00): Done some more digging.  It’s actually the street name that the sign in the window is referencing. 
(Double checked on planning portal)
Corrected to house. Nearby garage is correct as garage. 
When we lived there is was Jasmine Cottage. The village plan document (found online) also references this name.. so noted in description.
gurglypipe (2026-07-05 23:24:46+00:00): Super, thanks for checking and updating it :)
AndiBing (2026-07-05 23:57:01+00:00): :-)
Yog Sot (2026-07-05 22:32:40+00:00): nie no, jest, ale troche inaczej ;D
Yog Sot (2026-07-05 22:37:24+00:00): zastanawiam się aby ten fragmtn drogi obok ustawić private tylko dla pojazdów. Bo piesi nie wyglądają na wzbronionych
db-ak (2026-07-06 06:35:17+00:00): -No ta ukryta ściezka mnie zastanawiała, ale jej jakosć i sezonowość (dojazd do pola, albo dla quadów?) mnie zniechęciła.
-Ta droga prywatna jest nie jasna, w poprzedniej edycji się spytałem czy są jakieś zmiany w sytuacji.
- Relacja pierścienia dookoła Poznania mi sie nie podoba, ani poprowadzić tym przez pole, ani prywatną. Najlepiej ulicą Świerkową ale nie wiem czy można tak zmieniać
Yog Sot (2026-07-06 09:39:58+00:00): raczej przez to prywatne pole tbh xD
To jest cały urok tych szlaków, ze oni nie musza tak jak my faktycznie wszystko spiąć, tylko se wyznaczają jak w danym momencie im pykło ;]

Ten zakaz wjazdu prawie na bank oznacza wyłącznie pojazdy silnikowe w oczach tego prywatnego właściciela (I od strony tego zagajnika z ławkami pewno nie ma znaku), bo dla niego to po prostu problem. A piesi czy rowery, to się  nie przejmuje. 
Inaczej już dawno byłby płot (I ludzie pewno by wydeptali ścieżkę wzdłuż ;]
eggie (2026-07-05 11:45:32+00:00): Lijkt me oke.
Udarian (2026-07-05 14:12:28+00:00): it passes under a bridge so it is not a tunnel, please stop tagging it that way, also the rest f the Riverwalk in the area is tagged as an embankment so this one should also.

Happy mapping,
Udar
Kerry Irons (2026-07-05 17:00:00+00:00): Thank you.  What should it be tagged so that it appears to go under the bridge?  I've encountered similar situations where a path or way goes under a road, under a building, etc. and the only way I have figured out how to tag it so that it appears to go under the structure, is to tag it as a tunnel.  Help appreciated.
Udarian (2026-07-05 17:37:47+00:00): when a path goes under a building, if it is just a roof then it should be tagged with covered=* but if the path passes through the building (and doesn't go indoors since there is different tagging for that) then use tunnel=building_passage. I haven't been in the area my self and there isn't any streetside imagery in the area available in iD so I am not 100% sure but from what I can tell this pass under the span of the bridge not through the abutment. For more info see https://osmus.slack.com/archives/C2VJAJCS0/p1783271515914219 where I asked about this, use https://slack.openstreetmap.us/ if you haven't joined yet. 

Happy mapping,
Udar.
Kerry Irons (2026-07-05 22:14:55+00:00): Thanks.
Marvk (2026-07-05 14:23:46+00:00): Hi TornadoFang,

du hast hier traffic_calming=* anstatt traffic_sign=* getaggt :-)

Beste Grüße
Marv
nevw (2026-07-06 08:38:20+00:00): Hi, can you zoom in much closer when editing as the building lines are not true to imagery and you have ways joined to building edges.
https://www.pasteboard.co/bp-rzbk2ytcf.png
nevw (2026-07-06 08:47:51+00:00): I see you did not add these ill drawn buildings but were only fixing parts of the intersecting buildings. More work needed by others in time to fix it all.
nevw (2026-07-07 01:57:20+00:00): I have fixed this area now
eggie (2026-07-05 20:54:55+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht.
MVG,
Eggie
Namens de OSM Community
donux-nl (2026-07-12 21:22:46+00:00): Dag Erik, ik heb 'daglicht' bij twee poorten aangepast naar 'sunrise-sunset'. Zie de wiki: https://wiki.openstreetmap.org/wiki/Key:opening_hours
 Hopelijk ben je het daar mee eens. 
Groeten,
Donux
CAM-Gerlach_Repair (2026-07-05 18:48:47+00:00): Reverted adding SEO spam POI with blatant advertising and malformed tags/values in changeset:

https://osm.org/changeset/185156387
Tomas Straupis (2026-07-05 17:45:28+00:00): Eismo juostų atskirais vektoriais nežymime. Atstačiau tvarkingą ankstesnį žymėjimą.
HellMap (2026-07-05 19:12:35+00:00): Hi,

Thanks for you edits. A couple notes.

`bicycle` legal access values should not be set unless they are somehow posted, such as road signs. Basically, there would have to be a sign like "bicycles are allowed in the park" somewhere to set `bicycle=yes`, otherwise the value should stay empty and can be assumed to be default nationwide.

`access=permit` means that such a permit can be publicly obtained by anyone. This is very rare in Latvia and such roads are almost always just private - for residents, employees, etc. and not actual "permits".
Allroads (2026-07-06 09:19:51+00:00): Hoi, je maakt daar een aansluiting.
https://www.openstreetmap.org/way/1384965034
Je bekijkt ook de quick ortho 2026, volgens mij zie je dan, dat dat deel van pedestrian waaraan het aangesloten is een eigen vak is en heeft waarschijnlijk gras. Dat muurtje, is er niet meer, al kijkend naar het verder lopend muurtje naar rechts, aanwijzingen dat er wat veranderd is. Zie ook BGT. 
Het boules vak is te groot en dat eigenlijk de boomvlakken uit de pedestrian gehaald moeten worden, laatst zag ik daarvoor landuse=tree_pit, ze hebben ook nog een kerb, nog meer een reden om ze uit te knippen. En dan de schaduw werking, dan zie je dat een aantal bomen niet op zijn plaats staan, dit geeft BGT en AHN ook aan. De footway vlakbij de aansluiting, is nu getekend over een 15 cm muurtje (kerb op sidewalk) en sluit aan op de linker H.J. Schimmelplein.


Dit viel mij op basis van quick 2026.
En zo was dat verwijderen van dat stukje footway toch niet zo raar, verplaasten was beter geweest. Goede oplossing om de sidewalk in te tekenen als verbinding. Dan kan je het elders aansluiten.

Groeten Allroads.
Allroads (2026-07-06 09:24:14+00:00): BGT omtrekgericht over quick ortho 2026
https://app.pdok.nl/viewer/#x=135222.07&y=456353.39&z=16.0000&background=Luchtfoto&layers=a301ddc7-c26f-42d8-b367-509ae5ae47d0;2026_quickorthoHR;_;1,2891cc29-0a79-46d1-8649-287046d621c7;omtrekgerichtevisualisatie;_;1
Allroads (2026-07-06 09:39:26+00:00): En dan kijk ik nog even verder, twee aaneengesloten pedestrian, maar die pedestrian met voetbalveld ligt verdiept, met twee tredes, dat zie je niet terug in de tagging, wat o.a.  voor rolstoel routing toch een heel ander rout zou moeten opleveren.
DwarfNebula_ (2026-07-06 11:32:06+00:00): Ik zal eens aan de slag gaan met de nieuwe luchtbeelden. Kon op basis van de beelden van vorig jaar niet heel veel nauwkeuriger intekenen. Ook weer een jaartje verder, hoop geleerd zoals de bgt die voor dit soort dingen wel handig is. Dacht dat ik tussen beide plein delen een barrier had getekend, zoals aan de rechterkant, maar ik denk niet goed overgenomen naar de rest.
Allroads (2026-07-06 14:01:05+00:00): We leren elke dag, een trap zou area:highway=steps zijn. Dat zou niet aangesloten pedestrian betekenen. Een rand er tussen met verbinding over de trap als way.

Ik zag boven bij imagery used dat je niet
de beelden van vorig jaar heb gebruikt maar de 2026 beelden.
DwarfNebula_ (2026-07-06 15:05:54+00:00): Ja klopt, volgens mij ben ik halverwege mijn edit geswiched omdat ik zag dat het voetbalveld en basketbalveld niet gelijk lagen met de lijnen. Had dus niet gezien dat op de plek van dat verbindingsstukje nu gras ligt. Inmiddels aangepast :)
Yog Sot (2026-07-05 22:38:00+00:00): Połączyłeś linie napięcia z drogą. nie rób takich rzeczy
JJIglesias (2026-07-05 17:38:53+00:00): De donde sale esa RVF-61? en los mapas de la ABC 2025-2026 NO EXISTE dicha via. Tienes alguna referencia a una Ley que autorice esa via?
Gracias
StreetSurveyor (2026-07-11 10:25:29+00:00): Can you please explain your rationale for changing the access on Nina Court to private? If you have a source or on-the-ground observations supporting the change, I’d appreciate understanding the reasoning.
Sandonin (2026-07-07 19:10:59+00:00): Salut BePatman, merci pour ta contribution ! Pour ce qui est de la Rue Bara, je me suis permis de modifier ton intégration en incluant l'extrémité sur l'avenue Lacassagne (et en reprenant sa géométrie par cohérence avec l'usage qui doit se mettre en place). Deux questions subsistent :
- concernant les espaces verts, le chemin est amené à les traverser ?
- concernant la qualification du chemin lui-même, s'agit-il plutôt d'une rue piétonne, d'une voie cyclable, d'une voie verte, d'un chemin piéton (où les cyclistes ne seraient alors pas trop attendus) ?
Merci d'avance pour tes réponses !
BePatman (2026-07-09 12:56:07+00:00): Le chemin est en fait, le trottoir.
Ce bout de trottoir permet d'accéder à l'ilot qui est en fait un quai bus pour l'école Montbrillant plus loin (Impasse des Pins)
streckenkundler (2026-07-05 20:03:02+00:00): Hei, ich bin über https://www.knooppuntnet.nl/en/analysis/network/16069068 hierdrauf gestoßen... In Bezug auf Punkt https://www.openstreetmap.org/node/264070922 Dur hattest neben einigen anderen Dingen auch network:type=node_network gelöscht. In diesem Fall war das löschen von network:type=node_network an diesem Punkt falsch. Dieses network:type=node_network an den Knotenpunkten wie hier ist essentiell. Ich habe das wiederherhestellt: CS: https://www.openstreetmap.org/changeset/185160069

Danke,

Sven
tvbrene (2026-07-06 08:59:38+00:00): Ja, danke, war ein Versehen, ich wollte nur den Wegweiser an die korrekte Position versetzen.
streckenkundler (2026-07-06 14:55:55+00:00): Passiert... :) Durch https://www.knooppuntnet.nl/en/analysis/cycling/de/networks fällt sowas schnell auf.. Grüße, Sven
Ritam Saha (2026-07-10 15:59:34+00:00): In this changeset you edited the way 1535207566 by changing it's tag and connecting the way with another road because you probably thought they were connected, but in actuality they are not connected.
Ritam Saha (2026-07-10 16:01:03+00:00): Also I would have really appreciated if you had left a comment in my changeset before you changed it
osmviborg (2026-07-05 14:12:09+00:00): Hej, Et forsamlingshus bør også tagges med https://lgms.nl/p/osm/cached-wiki/?page=Tag:amenity%3Dcommunity_centre
旧加卷 (2026-07-05 22:43:04+00:00): name值请保留一个名称
Bisenz (2026-07-05 17:25:55+00:00): Konečně :) Co se děje, že dříve aktualizace adres na měsíční bází začínají skomírat? Přestává tě OSM bavit? I lenochod už tě přes komunitu "talk cz osm " prosil o aktualizaci... :)
flohoff (2026-07-05 18:07:44+00:00): Aehm - also das wird hier gerade nicht besser mit dem routing an der kreuzung ;)

Rot Alt - Grün Neu  :) 

https://osm.zz.de/routeqa/?rid=1299322,1299678
Blaues Licht (2026-07-05 18:29:54+00:00): Das Verhalten sollte jetzt nicht mehr auftreten :-)
morkovkin (2026-07-05 14:30:02+00:00): source=Esri World Imagery; Notes
user_5359 (2026-07-12 10:46:46+00:00): Hello! Please have a look on https://www.openstreetmap.org/way/1535584675
What is the mean of the tags DPS = Nord-Kivu
attributio = Référentiel Géographique Commun (RGC.cd)
health_lev = 8 (did you mean is_in:health_level8 = ...)
is_in_hl6 = Kibirizi (did you mean is_in:health_level6 = ...)
ref_CDsnis = 61250510 (did you mean ref:CD:snis)
ref_dhis2 = hQZQdiDIGSP (did you mean ref:dhis2 or general better ref:CD:dhis2)
source_dat = 2025 (did you mean source:date)
source_geo = CIESIN (did you mean source:geometry)
rajdhani (2026-07-07 15:30:20+00:00): Reverted in https://www.openstreetmap.org/changeset/185274146
Sylabowy Kot (2026-07-05 18:32:09+00:00): Thanks StreetComplete for such a big and senseless update.
ajmat (2026-07-06 11:35:23+00:00): Reverted in https://www.openstreetmap.org/changeset/185192054
CAM-Gerlach (2026-07-14 00:36:50+00:00): Hey Jake, thanks! I'd barely touched this area so far, so it really needed the love.

Just FYI, your work here inspired me to follow this up with some small changes in changeset 185685933 , to add a separate sidewalk plus crossings and links along the southern bit of Grissom Lane and updated the road tags accordingly, as well as added sidewalk tags to the the couple remaining streets in the area that didn't yet have them. 

https://osm.org/changeset/185685933
HellMap (2026-07-08 11:19:14+00:00): Jau vairākas reizes minēts, ka atsevišķi iezīmētas pārejas kā https://www.openstreetmap.org/node/13990411099 nevar dubultā atzīmēt kā saliņas.
jb54osm (2026-07-05 21:43:42+00:00): Hi dkywxkidxjirs,

We zetten POIs op de adresnode in Nederland.
We put POIs on the adresnode in The Netherlands.
dkywxkidxjirs (2026-07-06 14:38:16+00:00): Well, that is unfortunate. The CoMaps app does not support that. There are already PR's open for that but they do not look like they will be merged anytime soon. Any tips on how to do this easily on Android?
Chetan Hanumantha (2026-07-07 07:50:21+00:00): Changes are as per, approved plan :- https://canterburycastles.com/plugins/this-project-plugin/media/plots/masterplan.pdf
pitscheplatsch (2026-07-05 16:09:02+00:00): Hi, thanks for your contribution! I noticed that the name=* tag for this residential area is set to '362'. Could you please clarify how this name is verifiable, such as whether it appears on a sign or is commonly used locally as the feature name?
gurglypipe (2026-07-05 18:04:18+00:00): Can I ask why? Was something broken before? :)
tms13 (2026-07-05 20:31:28+00:00): Yes it was broken, as shown on OSM Inspector.
tms13 (2026-07-05 20:34:17+00:00): I actually fixed it once before, but it got broken again since then.
StC (2026-07-05 22:28:44+00:00): Bonjour,

ce changeset a brisé la continuité d'un itinéraire pédestre qui passe par là. Je m'occupe de la réparation.
Striddler (2026-07-05 15:52:14+00:00): And also some updates to sections of PA 414.
silversurfer83 (2026-07-06 19:47:29+00:00): Hi :)

eine Quellenangabe wäre bei diesen Einträgen sehr angebracht. 

cheers
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/185147840
ADAC Touristische InfoSysteme (2026-07-08 06:36:50+00:00): 
Thanks for updating the population figures. Please see https://wiki.openstreetmap.org/wiki/Key:population. The numbers are displayed without decimal points/commas
CAM-Gerlach (2026-07-06 18:44:21+00:00): You've got me very curious--where'd you find addr:unit:label=*? I don't see any documentation of it on the wiki, and the only non-trivial usage appears to be from a few VA/WV county address imports in 2023-2024 (e.g. https://osm.wiki/Lynchburg_VA_Area_Import ) where Minh suggested it in https://community.openstreetmap.org/t/proposed-import-of-rockbrige-county-va-address-points/102594/45 .

I definitely agree that something should be done about the current situation wrt that which is less than ideal, curious if there's been any followup movement after that. I asked Minh as well if he has any followup thoughts; feel free to join us there https://osmus.slack.com/archives/CA9RX1PPS/p1783363442218879

Thanks!
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/185148901
Jakesname (2026-07-06 23:25:53+00:00): Yeah it's a weird gap in the address tagging scheme-- you'd think there would be a standard by now that includes the info needed to write a correct address without addr:full=*. After doing some quick searching to see what was out there, I mostly threw it in since it doesn't conflict with any existing schemes so would be easy enough to remove or do an automated migration on if people decide a better way of doing it. I don't have strong opinions and wouldn't care if it was removed, but for a town with many secondary units, it would be nice for us to handle it somehow. Maybe I'll have to finally join the slack...
CAM-Gerlach (2026-07-07 06:58:14+00:00): Gotcha, thanks! Yeah, you'd really think we'd have some more progress solving this by now. After discussing it with Minh on Slack I ended up on [this OSM forum thread](https://community.openstreetmap.org/t/secondary-address-unit-designators/136660/) where the discussion on how to handle this has evolved considerably since then, and chimed in there--I encourage you to do so as well given this issue also matters to you!
HaPe-CZ (2026-07-25 18:04:06+00:00): A rarely used track is not the same as an unused track. In other words: an unused track is heavily overgrown with grass and even brush, but overgrowth alone does not indicate disuse—only low traffic.
GeoSylvaris (2026-07-05 16:34:27+00:00): good job! deepriver!
LordGarySugar (2026-07-07 00:41:24+00:00): Hi, thanks for adding these very detailed buildings! Would you be able to ensure that extensions are merged with their parent building, please? For example, https://www.openstreetmap.org/way/1535610169/ is not a separate building. You can of course use building:part=yes areas to represent the sections of different height.

Could I also ask that you add some short but meaningful changeset comments to explain what you're changing? The four hashtags don't convey any information (not sure what Malmö has to do with London?). Thanks.
ajmat (2026-07-06 09:59:42+00:00): Partially Reverted in https://www.openstreetmap.org/changeset/185187064
BC168 (2026-07-05 20:09:56+00:00): Moin,

die Firma, die den Container leert, heißt "Glas"? Oder wolltest du sagen, dass das ein Glascontainer ist?
gurglypipe (2026-07-05 18:23:29+00:00): Why? These are separate fields, and they were each tagged differently. Why have you coalesced them all to a single area?
tms13 (2026-07-05 20:32:15+00:00): Lots of ways containing same nodes.  Completely unnormalised.
tms13 (2026-07-05 20:37:45+00:00): If you think there should be a separate relation for each field, go ahead and split them up.  But they were not tagged differently as you claim - I was very careful to only include identically tagged areas in this relation and in the others.
gurglypipe (2026-07-05 21:03:26+00:00): Indeed, I see you have created two multipolygons: one for the lower pastures, and one for the upper (rough) ones.

Scanning quickly through your edits here, though, I see at least these two fields which were tagged differently and which are no longer represented: https://www.openstreetmap.org/changeset/185152204

More generally, I believe fields should always be mapped individually (either as an area or a multipolygon; personally I prefer the former because multipolygons are far too easy for people to break) because their use may change over time. In that eventuality, only the tagging has to be changed, rather than the more time consuming and error prone geometry.

This edit (185150976) also lost detail of the wall curves along the east side of the road (particularly just north of Braida Garth’s drive), all the gate nodes, and the farmyard area is missing a multipolygon type so isn’t rendered. There may be other problems I haven’t spotted yet.

I realise you set out to fix the OSM Inspector error for the moorland here (which I hadn’t spotted, good to know about), but completely reworking the valley to switch it to multipolygons can’t be a good use of anyone’s time. It’s bound to introduce additional errors like these.

It stings a bit in particular because I recently spent 10+ hours adding detail to Kingsdale, and I feel like what’s been done here has undone that (and removed the history of it, by deleting the areas). I realise you have probably spent quite a while on your edits too, though, in good faith.

I’m tempted to revert all the edits here and do a more focused fix myself on the OSM Inspector error on the moorland. It looks like that error is focused on Kingsdale Head, and the landuse could do with some more detail there anyway since their recent rewilding/planting projects. What would your thoughts be about that approach?