Can't find Places I created in the inaturalist.NZ Portal

I work only in the .NZ portal to avoid search problems that occurred for me in the past after I had unknowingly created some places and projects while logged into the Global portal.

Both in “Edit my Observations” and in “Create a Traditional Project”, Places I created are not found.

However, with the help of a fellow user who tested one of my Place names for me, I find the search for Places in Traditional Project creation is successful if logged into the Global portal:

https://forum.inaturalist.org/t/cant-add-a-place-i-created-as-boundary-to-a-traditional-project/6066

Testing in Edit Observations, I find the same is true there.

I can log in to the Global portal occasionally as needed to edit the Place for a Project, but I need to be able to Bulk Edit with searches for both place and Field. I can do this by filtering obs for field and value then copying the Field/Value part of that url into the url of an Edit Observations search, but in the NZ portal I am unable to filter to my Place, either before or after modifying the url.

I fear that if I attempt this from the global portal I will strike other difficulties, or at least forget where I am logged in.

Is this a known problem, is any solution planned, and does anyone have any other suggestions for filtering one’s own observations to Place, Field and Value, and preferably having the option to add further filters?

I have a suspicion that the root of your place problems is that you have created places that do not have a defined parent place. From the other thread you linked, I see the place in question here is called “Kaipatiki Creek Restoration site, Glenfield, Auckland, NZ”.

I can find it both on .org and .nz sites in the header search.

But I see that you cannot find it when searching for it in the context of a traditional project initiated on the .nz site.
00%20AM

For a traditional project place on the .org site, the options when you start typing “Kaipatiki” are numerous.
44%20AM

The solution here is to edit all of your places to assign an iNaturalist Standard Place as the place “parent”. Even though you gave it a name including a clear place hierarchy, iNaturalist needs to be explicitly told that this place is “descended” from a larger place.

In this case, you should select “Auckland, NZ” with the designation “state” (I know it’s technically a region, sorry about that), as indicated in the screen shot.

Once you add the Auckland parent place for all your Kaipatiki Creek places (maybe some can be deleted too?), your place searching problems should be resolved because they will all be recognized as clear descendants of the New Zealand standard place associated with iNaturalist.nz.

1 Like

Just so it doesn’t cause confusion, I wanted to let you know I already added Auckland as the parent place for Kaipatiki Creek Zone Za.

You can see place hierarchy (or lack thereof) at the top of each place page.
15%20AM

32%20AM

Seeing what tiny places these creek zones are that you created, I wanted to note that you could have a hierarchy of places where each zone is assigned a parent place of the entire watershed, and the watershed place is assigned to Auckland. But at the very least get them assigned to Auckland.

1 Like

Thanks very much for your work on this Carrie. I will check out the results of having the parent place assigned.

The reason none of them have a parent place is that last year I spent months creating and refining the 80 or so Kaipatiki Zones and other Kaipatiki Places, then due to searches not working and advice that having unknowingly created many of them created in the Global portal was the problem, I recreated them in the NZ Portal, logging in to the Global portal to find and delete the originals and numerous duplicates created then not previously findable for deletion. - after replacing them in the corresponding Collection Projects.

Unfortunately I did not realize that one of the 'unused" Places i created was in fact the one (Kaipatiki Creek restoration site) I had used as Parent for the 80 or so Zone Places. Deleting it resulted in the automatic deletion of all the 80, which meant all those Projects were now picking up the entire 14 million obs of iNat.

It took several weeks to recreate the Places, and when I learned that this automatic deletion was unavoidable I resolved not to add Parent places in future in case someone deletes that Place one day. Even though its unlikely in the case of an “official” place, it could happen.

I will reconsider that decision, and also whether there is less chance of accidental deletion of the Parent Place if it is an official place eg “State”, or one of my own.

It would be good if it were impossible to delete a Place being used as a Parent Place, cf. it is impossible to delete a Field which is in use.

2 Likes

By the way, once I learned to find in the Universal Search all the Places which were not findable in the “Find a Place” search, I went through every one, checking each out to find whether it was used, and deleting the duplicates. I noticed recently that duplicates appear to have been created for some I had only just made. I have not yet had time to Universal Search, check out both places, and choose one to delete. This is a time-consuming process since Search results don’t indicate whether the Place was created Globally or in the local Portal or whether it is use. These duplicates also present problems in choosing the correct option in drop-downs. sorry, I don’t have time at present to reproduce and send links or screenshots, but I will when i can. I wonder if it is to do with the two-stage Save process in Place creation - saving the Polygon then saving the page?

Thanks again Carrie, Confirming that the Place to which you assigned the PArent is now findable in my Edit Observations when logged into the NZ portal :)

Before I add parents to the other 100 or so Places, I will wait for the outcome of your query in another thread about correction of the standard places for Auckland, and any solution to the deletion of Parent Places in the unforeseeable future resulting in deletion of its Child places.

To my horror and surprise, I can replicate this. I’m sorry that it created so much extra work for you. I’ve filed an issue. In the meantime, since only staff can delete standard places, you should be safe in assigning standard places as parents.

2 Likes

Thank you Carrie, it is a great relief to have a possible resolution of this issue. The incident happened at the end of last year when I was already tired from the delightful discovery of iNat leading to my applying for funding for a restoration study and action Project on the Creek. I had spent hundreds of hours struggling through dense undergrowth on challenging terrain to locate old landmarks and make new observations, using this wonderful feature of geotagging from which to derive and map geographical micro-site or “Zone” boundaries allowing 20 year old photos (untagged of course) and hundreds of hours uploading both old and new photos as iNat obs, comparing 20-yr -old obs with current ones in the same micro-sites.

I was not at the time aware of geo-tracing, which I recently discovered but can not yet use to geotag photos, so I created each “Zone” Place based on the locations of current obs which of course were not perfectly located, and often failed to record location at all.

So the creation of those Places took many hundreds of hours. Then when i learned how to find the “disappeared” Places using Universal search I did the “tidy up” of deleting unused ie duplicate places - after checking the one being deleted was not the one used in a Project - then there was the sudden horror of seeing that all the iNat obs that existed were being collected in each Project, doing goodness-knows what to iNat Server load, having no idea why except that I had undoubtedly caused it by deleting Places. I spent that night spent frantically de-populating 60-odd Projects by adding one of the few places that survived deletion (because I was then unaware of the option of Exclusion from Projects, which might have been faster); then days struggling to learn to use the old google-forum for help, the discouraqing news that my undertaking might be considered excessive use of iNat, my consideration of abandoning both the iNat and onsite projects, and then weeks recreating the Places, somewhat more quickly this time because I had already learned to use the iNat features and had learned something of the site’s geography, but still requiring many tweaks to each Place over subsequent months. Editing Places is a slow process because it takes a day or two before each change becomes visible, eg in the Umbrella Project overview map, the only place to see multiple Places side by side, I believe?

Anyway, I managed it in the end, I really appreciate the facility to do it, and I am delighted to hear that this is an issue that might be resolved. I would appreciate an update on this when possible.

In case of future errors on my part, I don’t suppose there is any way for a user to “back up” their Places and Projects?

1 Like

@kaipatiki_naturewatc I’m so sorry again for all the time and hassle that this bug caused you. I am happy to report now that the cascading deletion of places has been eliminated. Now, if a parent place is deleted, the “child” places will be assigned to the next-level place in the hierarchy, whether it is a community-curated place or a standard place.

1 Like

Thanks Carrie…for the empathy and the investigation and the bug-fix.
Just so I understand, would there always be a next level place in the hierarchy, eg Country perhaps, that cannot be removed?

Oh, and thanks for the solution to my not being able to find Places, too:)

It depends on what you assign as a parent in the first place, and if that has a standard place somewhere in the hierarchy. For example, if you make a place in the ocean where there’s not a standard place, and then make smaller places and assign them to that parentless ocean place, if you delete parentless ocean place your smaller places wouldn’t have anything higher in the hierarchy to attach to.

But for your use case, as long as there’s a New Zealand-related standard place somewhere in the hierarchy, it shouldn’t end up completely orphaned and parentless.

thanks Carrie.

By the way, using Auckland (State) as a parent results in places displaying somewhere as “… AU, NZ” which is misleading to us in NZ, because AU is the standard abbreviation for Australia, whereas Auckland is usually abbreviated to AUCK or AKL or AK. I hesitate to suggest a change lest that break something, but just mentioning that.

1 Like

And in case you, like many of your compatriots, are confused - NZ is distinct from australia and 1000 miles away across the Tasman Sea:).

Husband and I frequently had to explain that when living in Arlington, Va in the 1980s…which reminds me, say hi to the lovely Rock Creek Parkway and the City of Trees for me:)

1 Like

Ah, it’s like we traded places. Many years ago I spent 9 months in NZ and someday I will actually go through our photos from all over the country and upload them. :-) I have many fond memories from NZ and hope to return one day. Treegrow is the one to follow for a virtual tour of Rock Creek Park :-)

1 Like

Thanks Carrie, I’ll have a look.

@carrieseltzer Thanks for that help, things are going much more smoothly now:)

I found I could edit the “Display” name, so I changed “AU” (for Auckland) to “AK” as that is more consistent with …well, life in Auckland.

Since the option to edit is was there, I assume this does not interfere with anything in the system? Is there any chance that editing the Display portion of a name could have adverse effects such as bugs (esp automatic deletion of Places!) , or human confusion?

Editing the display name should not have any adverse effects, but please let us know if you encounter anything odd.

1 Like

Thanks Carrie. i decided not to at present, just in case, and edited the display name back to AU.