[Arches] Re: Arches 5 Documentation Sprint: Call for Suggestions and Feedback

[Martha S]

Thank you, Intrepid Documenters,

This is much-appreciated. I would like to see SSL added to the 
documentation. I know this will be a requirement for us and I'd like to 
have as straightforward a shot at success as I can get.

Martha

On Thursday, June 4, 2020 at 9:45:59 AM UTC-7, Adam Cox wrote:
>
> Hello everyone,
>
> Angela Labrador and I are planning to coordinate a community-oriented 
> documentation writing sprint to bring the current Arches documentation 
> up-to-date with the most recent release, v5.0 as best as we can. Hopefully 
> we can also address some aspects of the documentation that needed attention 
> prior to the update.
>
> We'd like to begin by soliciting feedback from all forum members on the 
> following:
>
>- Which aspects of the documentation have you found confusing or 
>misleading?
>- Are there topics that you would like to see added to the official 
>documentation?
>
> Please respond with your thoughts in this thread or email us directly. 
> Feel free to second other people's posts if someone has already mentioned 
> the same thing you were thinking--more input is better than less at this 
> stage.
>
> We'll begin comparing your ideas with known documentation "to-dos" as 
> recorded in the arches-docs issue tracking. 
> Then we can put out 
> a call for help, especially to those most knowledgeable in these specific 
> topics, and start organizing a "sprint" of a few days where we can make 
> some real progress on the content itself.
>
> We won't get everything perfect, but hopefully a concerted and coordinated 
> effort can make some big improvements.
>
> Adam
>

-- 
-- To post, send email to archesproject@googlegroups.com. To unsubscribe, send 
email to archesproject+unsubscr...@googlegroups.com. For more information, 
visit https://groups.google.com/d/forum/archesproject?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to archesproject+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/archesproject/d5211b0c-7277-440a-813f-273b1febeaffo%40googlegroups.com.

[Arches] Re: Arches 5 Documentation Sprint: Call for Suggestions and Feedback

[Mahmoud Abdelrazek]

Hi Adam, 

Thank you so much for stating this. I would like to participate in this 
great effort. 
One page of documentation which I would like to start working on is *an 
update to arches installation on ubuntu server*. I have seen similar pages 
in previous versions of arches like this 
 
but 
I believe that a similar one for version 5 doesn't exist yet. I would like 
to try to make this installation process as approachable as possible. The 
aim is to enable the user to install arches on a ubuntu server virtual 
machine which replicates what I assume most of the active implementations 
of arches currently online. I am sure that this will require me to ask many 
questions and learn new concepts, and I would rely on the knowledge and 
generosity of our community to guide my steps. I hope this will be a useful 
addition to the documentation. 

Best, 
Mahmoud 
On Thursday, June 4, 2020 at 6:45:59 PM UTC+2, Adam Cox wrote:
>
> Hello everyone,
>
> Angela Labrador and I are planning to coordinate a community-oriented 
> documentation writing sprint to bring the current Arches documentation 
> up-to-date with the most recent release, v5.0 as best as we can. Hopefully 
> we can also address some aspects of the documentation that needed attention 
> prior to the update.
>
> We'd like to begin by soliciting feedback from all forum members on the 
> following:
>
>- Which aspects of the documentation have you found confusing or 
>misleading?
>- Are there topics that you would like to see added to the official 
>documentation?
>
> Please respond with your thoughts in this thread or email us directly. 
> Feel free to second other people's posts if someone has already mentioned 
> the same thing you were thinking--more input is better than less at this 
> stage.
>
> We'll begin comparing your ideas with known documentation "to-dos" as 
> recorded in the arches-docs issue tracking. 
> Then we can put out 
> a call for help, especially to those most knowledgeable in these specific 
> topics, and start organizing a "sprint" of a few days where we can make 
> some real progress on the content itself.
>
> We won't get everything perfect, but hopefully a concerted and coordinated 
> effort can make some big improvements.
>
> Adam
>

-- 
-- To post, send email to archesproject@googlegroups.com. To unsubscribe, send 
email to archesproject+unsubscr...@googlegroups.com. For more information, 
visit https://groups.google.com/d/forum/archesproject?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to archesproject+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/archesproject/8bd222b1-c2ba-4126-9589-cf659f53e536o%40googlegroups.com.

[Arches] Uploading photos via Arches Collector and duplicate filename woes

[Angela Labrador]

Hi Arches Collector fans,

I've been experiencing the following issue, and wondering if this is 
expected behavior or a bug:

I have a resource model that basically amounts to a condition assessment 
report with a file-list node for uploading photos.

   1. I submit a report with a photo from my phone through the collector
   2. Sync the project 
   3. Resulting report is perfect online
   4. I submit a second report with a new photo from my phone through the 
   collector
   5. Sync the project 
   6. Resulting new report is perfect -- BUT the photo in the first report 
   is overwritten by the second report's photo

This seems to be caused by how the collector defaults to naming photos 
"1.jpg" (rather than using the phone's native filename or uid) -- and so, 
when the second report is synced to the server, the new photo overwrites 
the previously uploaded "1.jpg"

Is this expected? Are collector users supposed to manually set a filename? 
If so, how will they know it's a filename not in use?

It seems as though the process_mobile_data method in datatypes.py would be 
a convenient place to rename files with a uuid or something? It looks like 
it's doing some logic to that effect for individual instances (in the case 
of multiple photos uploaded per report) but not across all existing files.  

As an aside, Arches appears to have the same behavior, but I just haven't 
encountered the problem because the upload widget doesn't default to 
"1.jpg" but instead uses the filename provided by the computer, so there's 
a smaller chance of duplicate names. 

In both cases, this could become quite a problem as it basically allows 
users to overwrite existing uploaded files without a warning. 

I welcome all ideas and reflections -- especially among those of you 
dealing with large databases containing lots of uploaded media! (If it 
matters, this is in an environment where media files are being stored in 
aws s3 bucket.)

Thanks!

Angela

-- 
-- To post, send email to archesproject@googlegroups.com. To unsubscribe, send 
email to archesproject+unsubscr...@googlegroups.com. For more information, 
visit https://groups.google.com/d/forum/archesproject?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to archesproject+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/archesproject/35d363b3-894d-41e5-bce9-d4848a08bb64o%40googlegroups.com.

[Arches] Re: Setting DATE_IMPORT_EXPORT_FORMAT for Collector

[Angela Labrador]

Thanks, Alina! 

I've coded a workaround that parses the date, at least according to the 
formats that I've encountered on a few different android and ios devices. 
It's probably not robust enough for a pull request, but if anyone else has 
been dealing with this problem, I'm happy to explain what I did (edits are 
mainly in 
https://github.com/legiongis/arches/blob/stable/5.0.x-fpan-dateparse/arches/app/datatypes/datatypes.py
 and  
https://github.com/legiongis/arches/blob/stable/5.0.x-fpan-dateparse/arches/app/models/mobile_survey.py
)

Angela







On Friday, April 3, 2020 at 9:05:14 PM UTC-4, Alina Myklebust wrote:
>
> Hi Angela,
>
> I also experienced a similar issue with syncing dates using the Collector 
> app in version 4.4.3.  If I recall correctly, the issue was logged in 
> Github.  
>
> I'll check with the app developers to see if there is an update.  
>
> Best,
>
> Alina
>
>
>
> On Wednesday, April 1, 2020 at 1:55:40 PM UTC-7, Angela Labrador wrote:
>>
>> Hi everyone, 
>>
>> I'm running into a problem syncing a date using the Collector app in 
>> Arches 5 (and previously in 4). I'm getting the following error:
>>
>> arches.app.models.tile.TileValidationError: '2020-04-02T00:00:00.000-04:00 
>> None is not in the correct format, make sure it is in this format: 
>> %Y-%m-%d or set the date format in 
>> settings.DATE_IMPORT_EXPORT_FORMAT. This data was not imported.'
>>
>>
>> and so I added in my settings_local.py file:
>> DATE_IMPORT_EXPORT_FORMAT = ['%Y-%m-%dT%H:%M:%S.%fZ', 
>> '%Y-%m-%dT%H:%M:%S.%f%z 
>> %Z', '%Y-%m-%dT%H:%M:%S.%f%z', '%Y-%m-%dT%H:%M:%S.%-f%z %Z']
>>
>>
>> However, none of these match the format string (I'm most unsure of the 
>> last portion with the milliseconds and time zone). 
>>
>> Back in the Arches' project resource model, the node is datatype = date, 
>> and the card widget is using date format ISO 6801 -MM-DD. No project 
>> overrides on any of these. In the collector app, I get the standard pop up 
>> calendar and can choose a date (no time). 
>>
>> Grateful for ideas. Thanks,
>> Angela
>>
>

-- 
-- To post, send email to archesproject@googlegroups.com. To unsubscribe, send 
email to archesproject+unsubscr...@googlegroups.com. For more information, 
visit https://groups.google.com/d/forum/archesproject?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to archesproject+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/archesproject/70553905-be0b-4557-be0c-c7bd0c964774o%40googlegroups.com.

[Arches] Re: Arches 5 Documentation Sprint: Call for Suggestions and Feedback

[Neil Silberman]

Excellent way to prioritize the documentation rewrite/expansion. I'm ready 
to start writing too. 

Neil

On Thursday, June 4, 2020 at 12:45:59 PM UTC-4, Adam Cox wrote:
>
> Hello everyone,
>
> Angela Labrador and I are planning to coordinate a community-oriented 
> documentation writing sprint to bring the current Arches documentation 
> up-to-date with the most recent release, v5.0 as best as we can. Hopefully 
> we can also address some aspects of the documentation that needed attention 
> prior to the update.
>
> We'd like to begin by soliciting feedback from all forum members on the 
> following:
>
>- Which aspects of the documentation have you found confusing or 
>misleading?
>- Are there topics that you would like to see added to the official 
>documentation?
>
> Please respond with your thoughts in this thread or email us directly. 
> Feel free to second other people's posts if someone has already mentioned 
> the same thing you were thinking--more input is better than less at this 
> stage.
>
> We'll begin comparing your ideas with known documentation "to-dos" as 
> recorded in the arches-docs issue tracking. 
> Then we can put out 
> a call for help, especially to those most knowledgeable in these specific 
> topics, and start organizing a "sprint" of a few days where we can make 
> some real progress on the content itself.
>
> We won't get everything perfect, but hopefully a concerted and coordinated 
> effort can make some big improvements.
>
> Adam
>

-- 
-- To post, send email to archesproject@googlegroups.com. To unsubscribe, send 
email to archesproject+unsubscr...@googlegroups.com. For more information, 
visit https://groups.google.com/d/forum/archesproject?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to archesproject+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/archesproject/8d54b14b-19d8-4f1c-9e8d-56a9eb3d9079o%40googlegroups.com.

[Arches] Arches 5 Documentation Sprint: Call for Suggestions and Feedback

[Adam Cox]

Hello everyone,

Angela Labrador and I are planning to coordinate a community-oriented 
documentation writing sprint to bring the current Arches documentation 
up-to-date with the most recent release, v5.0 as best as we can. Hopefully 
we can also address some aspects of the documentation that needed attention 
prior to the update.

We'd like to begin by soliciting feedback from all forum members on the 
following:

   - Which aspects of the documentation have you found confusing or 
   misleading?
   - Are there topics that you would like to see added to the official 
   documentation?

Please respond with your thoughts in this thread or email us directly. Feel 
free to second other people's posts if someone has already mentioned the 
same thing you were thinking--more input is better than less at this stage.

We'll begin comparing your ideas with known documentation "to-dos" as 
recorded in the arches-docs issue tracking. 
Then we can put out a 
call for help, especially to those most knowledgeable in these specific 
topics, and start organizing a "sprint" of a few days where we can make 
some real progress on the content itself.

We won't get everything perfect, but hopefully a concerted and coordinated 
effort can make some big improvements.

Adam

-- 
-- To post, send email to archesproject@googlegroups.com. To unsubscribe, send 
email to archesproject+unsubscr...@googlegroups.com. For more information, 
visit https://groups.google.com/d/forum/archesproject?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to archesproject+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/archesproject/db487950-423b-4cd0-8ca5-cafaf88fb939%40googlegroups.com.

Re: [Arches] v5 documentation

[Adam Cox]

Hi all, very happy to see so much interest.

Angela has reached out to me and said she is happy to co-coordinate, so we 
will begin moving forward.

I think a good way to start will be to open up a new thread here on the 
forum to call for community feedback: What have people found confusing in 
the documentation, What aspects are missing, etc. When we have a list of 
topics we can then see about divvying them up and asking for volunteers to 
help with each one.

Adam



On Monday, May 18, 2020 at 12:03:44 AM UTC-5, Lily Pregill wrote:
>
> Hi Adam,
>
> Thanks for the great suggestion. I'm in, too!
>
> Best,
> Lily
> --
> *From:* Dennis Wuthrich 
> *Sent:* Saturday, May 16, 2020 9:37 AM
> *To:* Angela Labrador 
> *Cc:* Adam Cox ; Lily Pregill ; 
> Mahmoud Abdelrazek ; Arches Project <
> archesproject@googlegroups.com>
> *Subject:* Re: [Arches] v5 documentation 
>  
> Adam, 
>
> Thanks for suggesting a sprint to improve documentation for v5.  Great 
> idea!
>
> I’m happy to participate as well.
>
> -Dennis
>
> Dennis Wuthrich
> CEO Farallon Geographics  |  www.fargeo.com
> 601 Montgomery St, Suite 1095 | San Francisco, CA  94111
> T 415 227 1140  |  Cell 415 317 2771
>
>
>
>
>
> On May 13, 2020, at 1:38 PM, Angela Labrador  wrote:
>
> Hi all, 
>
> I would be happy to pitch in on a documentation sprint! Count me in. :-)  
>
> Angela
>
> On Wed, May 13, 2020 at 1:52 PM Adam Cox  wrote:
>
> Hi Lily and Mahmoud, really, you're both right. A little of the structural 
> work to set the documentation version to 5 has been done (as Mahmoud 
> pointed out), however, to my knowledge there has been no concerted effort 
> since the release of v5 to actually update the documentation in a holistic 
> manner--just bits and pieces like software requirements, etc. I think a few 
> days of a coordinated "documentation sprint" would go a really long way 
> toward fixing that. I would be happy to play some sort of role in such an 
> effort, because it would benefit the community hugely (obviously), but 
> can't commit at this time to fully coordinating it... perhaps 
> co-coordinating.
>
> If others are interested in contributing their time or resources, I think 
> we should use this thread to begin planning. I will also note that the 
> documentation repo (https://github.com/archesproject/arches-docs) has its 
> own issue ticketing system, so collecting to-do task in there is always 
> good (they are plenty of them already!).
>
> Adam
>
> On Tue, May 12, 2020 at 2:31 PM Lily Pregill  wrote:
>
> Thanks Mahmoud! I was looking at: 
> https://arches.readthedocs.io/en/stable/overview/ and the version says 
> 4.4.1.
>
> On the v5 version, the page title of the Overview page reads "Overview 
> 4.4.1" so something to fix.
>
> best,
> Lily
>
>
>
>
> --
> *From:* archesproject@googlegroups.com  
> on behalf of Mahmoud Abdelrazek 
> *Sent:* Tuesday, May 12, 2020 12:11 PM
> *To:* Arches Project 
> *Subject:* [Arches] Re: v5 documentation 
>  
> Hi Lily,  
>
> I am not sure if this is what you are looking for, but here is a link to 
> v5 documentation https://arches.readthedocs.io/en/5.0.0/
>
> Best regards,
> Mahmoud 
>
> On Tuesday, May 12, 2020 at 8:55:21 PM UTC+2, Lily Pregill wrote: 
>
> Hello, 
>
> Does anyone know if the current documentation has been updated for v5? The 
> version history does not reflect v5:
>
> v4.4 February, 2019: Release of Arches Collector 
>  mobile 
> data collection app
>
> v4.0 July, 2017: Significant site redesign, addition of graph creation UI, 
> system settings UI, internal tileserver (TileStache), updated dependencies 
> (MapBox GL, ElasticSearch 5.2, Yarn)
>
> v3.0 April, 2015: Updated architecture, inclusion of the Reference Data 
> Manager, updated dependencies (ElasticSearch, OpenLayers, Knockout)
>
> v2.0 March, 2014: Improved upload of digital files, assorted bug fixes
>
> v1.0 October, 2013: Initial Release
>
>
> Thanks,
>
> Lily
>
>
> *Lily Pregill*, Systems Architect | The J. Paul Getty Trust | (310) 440 
> 6394  |  getty.edu 
>
>
>
> -- 
> -- To post, send email to archesproject@googlegroups.com. To unsubscribe, 
> send email to archesproject+unsubscr...@googlegroups.com. For more 
> information, visit https://groups.google.com/d/forum/archesproject?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Arches Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to archesproject+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/archesproject/6749807d-07b4-43e4-b5ca-f76dc059d0c8%40googlegroups.com
>  
> 
> .
>   *CAUTION: This email originated from outside of the Getty. Do 

[Arches] Re: add_tileserver_layer is not available in Arches v5

[Dennis Wuthrich]

Hi Harri,

You should confirm that you are referencing your geoserver layer properly.  
Check to confirm that you have a map layer definition that looks something 
like so:

[{"id": "test-raster", "type": "raster", "source": "test-raster"}]

where test-raster is the name you gave your map source.  Assuming you've 
done this, you should confirm that you've set your CORS policy properly.  I 
get the following error when trying to access your Geoserver layer in Arches

Access to fetch at 
'http://vps815520.ovh.net:8080/geoserver/hk/wms?service=WMS=1.1.1=GetMap=1565430.3392804079,5948635.289265558,1878516.4071364924,6261721.357121639=image/png=EPSG%3A3857=256=256=hk:ostia'
 
from origin 'http://localhost:8000' has been blocked by CORS policy: No 
'Access-Control-Allow-Origin' header is present on the requested resource. 
If an opaque response serves your needs, set the request's mode to 
'no-cors' to fetch the resource with CORS disabled.



Hope this points you in the proper direction.

-Dennis





On Thursday, June 4, 2020 at 8:31:59 AM UTC-7, Harri Kiiskinen wrote:
>
> Hi all,
>
> (if it would be better to start a new subject for this, let me know)
>
> I've been trying to get the following layer visible in Arches:
>
>
> http://vps815520.ovh.net:8080/geoserver/hk/wms?service=WMS=1.1.0=GetMap=hk%3Aostia=1367121.2720044549%2C5123218.583961782%2C1369226.8194238057%2C5125090.037473778=768=682=EPSG%3A3857=application/openlayers
>
> The map source definition is like this:
>
> {"type": "raster", "tiles": ["
> http://vps815520.ovh.net:8080/geoserver/hk/wms?service=WMS=1.1.1=GetMap={bbox-epsg-3857}=image/png=EPSG%3A3857=256=256=hk:ostia
>  
> "],
>  
> "tileSize": 256}
>
> which to me looks very much like it should be according to the examples in 
> this thread. Also
> - the map is visible as overlay
> - the geoserver log files actually show the requests coming to the server 
> from arches, and there are no error messages
> - the bbox in the request covers the bbox of the map in the geoserver 
> layer definitions.
>
> And I still cannot see anything in Arches.
>
> Any suggestions on where to look? My installation is very recent, like 
> this week monday, and "pip list" shows arches version 5.0.
>
> Otherwise things seem to work as they should.
>
> Best,
>
> Harri Kiiskinen
>
>
> torstai 16. huhtikuuta 2020 21.57.53 UTC+3 Dennis Wuthrich kirjoitti:
>>
>> Hi Robin,
>>
>> You should check your geoserver configuration to see why the tiff 
>> disappears at certain zoom levels.
>>
>> As to your second question: Arches automatically zooms reports to the 
>> instance geometry (if it exists).  If your instance is represented by a 
>> point geometry, then the map does get zoomed in pretty close.  You could 
>> write an ticket requesting an enhancement to Arches at the github 
>> repository that summarizes this issue.
>>
>> Cheers,
>>
>> Dennis
>>
>> On Wednesday, April 15, 2020 at 2:53:27 AM UTC-7, Robin Rönnlund wrote:
>>>
>>> Dear Dennis,
>>>
>>> Thank you so much for this! Yes, it did work (almost), and I am very 
>>> much relieved!
>>>
>>> What is still weird, though, is that at certain zoom levels, the map 
>>> partially or wholly disappears:
>>>
>>> [image: Screenshot from 2020-04-15 12-46-28.png]
>>>
>>> Here it is visible.
>>>
>>>
>>> [image: Screenshot from 2020-04-15 12-46-33.png]
>>> But at a closer level, the middle disappears.
>>>
>>> [image: Screenshot from 2020-04-15 12-46-39.png]
>>> Even closer, more disappears...
>>>
>>>
>>> Is there something I should do?
>>>
>>>
>>> Also, additional question! :) Is there a way of setting the default zoom 
>>> level for individual resource models? Right now, the default is that you 
>>> start on a ridiculously close level:
>>>
>>> [image: Screenshot from 2020-04-15 12-46-48.png]
>>> ...and nothing can be seen...
>>>
>>>
>>>
>>> All my very best from Athens, Greece
>>> Robin
>>>
>>>
>>> Den onsdag 15 april 2020 kl. 01:08:12 UTC+3 skrev Dennis Wuthrich:

 Robin,

 Set the map source name to "kalaureia-plan" (this is what you reference 
 in the map layers json).  Also, you may want to add =true to 
 the URL in the map source (this will make your overlay transparent in 
 areas 
 outside of the tif).  I made these small changes and can view your 
 geoserver service in Arches:





 On Tuesday, April 14, 2020 at 1:34:34 AM UTC-7, Robin Rönnlund wrote:
>
> Dear Dennis and Adam,
>
> I followed these instructions to the letter, all very nice, thank you! 
> I did everything, there were no protests from geoserver, nor when I added 
> the layers etc. The map layer turned up in Arches, I could modify it as I 
> liked, but... The map does not actually turn up. What do I do wrong?
>
> My geotiff is in EPSG:3857 and I did the following:
>
> 1. Uploaded the 

[Arches] Re: add_tileserver_layer is not available in Arches v5

[Harri Kiiskinen]

Hi all,

(if it would be better to start a new subject for this, let me know)

I've been trying to get the following layer visible in Arches:

http://vps815520.ovh.net:8080/geoserver/hk/wms?service=WMS=1.1.0=GetMap=hk%3Aostia=1367121.2720044549%2C5123218.583961782%2C1369226.8194238057%2C5125090.037473778=768=682=EPSG%3A3857=application/openlayers

The map source definition is like this:

{"type": "raster", "tiles": 
["http://vps815520.ovh.net:8080/geoserver/hk/wms?service=WMS=1.1.1=GetMap={bbox-epsg-3857}=image/png=EPSG%3A3857=256=256=hk:ostia;],
 
"tileSize": 256}

which to me looks very much like it should be according to the examples in 
this thread. Also
- the map is visible as overlay
- the geoserver log files actually show the requests coming to the server 
from arches, and there are no error messages
- the bbox in the request covers the bbox of the map in the geoserver layer 
definitions.

And I still cannot see anything in Arches.

Any suggestions on where to look? My installation is very recent, like this 
week monday, and "pip list" shows arches version 5.0.

Otherwise things seem to work as they should.

Best,

Harri Kiiskinen


torstai 16. huhtikuuta 2020 21.57.53 UTC+3 Dennis Wuthrich kirjoitti:
>
> Hi Robin,
>
> You should check your geoserver configuration to see why the tiff 
> disappears at certain zoom levels.
>
> As to your second question: Arches automatically zooms reports to the 
> instance geometry (if it exists).  If your instance is represented by a 
> point geometry, then the map does get zoomed in pretty close.  You could 
> write an ticket requesting an enhancement to Arches at the github 
> repository that summarizes this issue.
>
> Cheers,
>
> Dennis
>
> On Wednesday, April 15, 2020 at 2:53:27 AM UTC-7, Robin Rönnlund wrote:
>>
>> Dear Dennis,
>>
>> Thank you so much for this! Yes, it did work (almost), and I am very much 
>> relieved!
>>
>> What is still weird, though, is that at certain zoom levels, the map 
>> partially or wholly disappears:
>>
>> [image: Screenshot from 2020-04-15 12-46-28.png]
>>
>> Here it is visible.
>>
>>
>> [image: Screenshot from 2020-04-15 12-46-33.png]
>> But at a closer level, the middle disappears.
>>
>> [image: Screenshot from 2020-04-15 12-46-39.png]
>> Even closer, more disappears...
>>
>>
>> Is there something I should do?
>>
>>
>> Also, additional question! :) Is there a way of setting the default zoom 
>> level for individual resource models? Right now, the default is that you 
>> start on a ridiculously close level:
>>
>> [image: Screenshot from 2020-04-15 12-46-48.png]
>> ...and nothing can be seen...
>>
>>
>>
>> All my very best from Athens, Greece
>> Robin
>>
>>
>> Den onsdag 15 april 2020 kl. 01:08:12 UTC+3 skrev Dennis Wuthrich:
>>>
>>> Robin,
>>>
>>> Set the map source name to "kalaureia-plan" (this is what you reference 
>>> in the map layers json).  Also, you may want to add =true to 
>>> the URL in the map source (this will make your overlay transparent in areas 
>>> outside of the tif).  I made these small changes and can view your 
>>> geoserver service in Arches:
>>>
>>>
>>>
>>>
>>>
>>> On Tuesday, April 14, 2020 at 1:34:34 AM UTC-7, Robin Rönnlund wrote:

 Dear Dennis and Adam,

 I followed these instructions to the letter, all very nice, thank you! 
 I did everything, there were no protests from geoserver, nor when I added 
 the layers etc. The map layer turned up in Arches, I could modify it as I 
 liked, but... The map does not actually turn up. What do I do wrong?

 My geotiff is in EPSG:3857 and I did the following:

 1. Uploaded the tiff to the geoserver directory.
 2. Added the tiff through Add stores/GeoTiff
 3. Went to /admin/ and added the tiff through "Map sources"

 {"type": "raster", "tiles": ["
 https://pragmata2.sia.uu.se/geoserver/Pragmata/wms?bbox={bbox-epsg-3857}=image/png=WMS=1.1.1=GetMap=EPSG:3857=256=256=Pragmata:kalaureia-plan;],
  
 "tileSize": 256}

 Saved etc.

 4. Added it as a map layer

 [{"id": "kalaureia-plan", "type": "raster", "source": "kalaureia-plan"}]

 5. Went to Arches and it is there among the overlays, and I activated 
 it.

 Still no show.

 Hope you can help me!

 Robin

 Den onsdag 1 april 2020 kl. 01:41:06 UTC+3 skrev Dennis Wuthrich:
>
> Adam,
>
> Thanks for providing a summary of using Geoserver to serve Geotiffs, 
> particularly the details of creating a layer group, supporting 
> transparency, and the extra explanation of how to structure the URL 
> properly.  Very nice!  I also really like the django fixture; it's a nice 
> way to avoid the button clicks that my approach summarized.
>
> I very much appreciate the time you took to write this up and share it 
> with the community!
>
> Cheers,
>
> Dennis
>
> On Tuesday, March 31, 2020 at 2:25:29 PM UTC-7, Adam Cox wrote:

[Arches] Re: Updated Arches Roadmap - What's new in 2020?

[Adam Cox]

Hi David, I have posted a question related to this in the Arches developer 
forum in case you are interested: 
https://groups.google.com/forum/#!topic/arches-dev/VRk2ws0yMbo

Adam

On Tuesday, March 3, 2020 at 9:02:28 AM UTC-6, David Osborne wrote:
>
> Hi Alison
>
> Thanks for your reply and explaining the background to the Arches/Arc 
> integration project. We will all have our own priorities so my comments 
> were not meant to be unappreciative of the development. I applaud Historic 
> England for helping to fund the initiative, particularly if it helps to 
> enable integration with other software such as QGIS!
>
> Best wishes
> David
>
> On Thursday, 13 February 2020 18:32:25 UTC, Alison Dalgity wrote:
>>
>> Greetings David. I should have replied to you (and Alina) a long time 
>> ago. My apologies.
>>
>> You make an excellent point David, and I would venture to say that most 
>> of us agree with you--i.e., that our priority should be to develop 
>> integration with other open-source rather than proprietary tools. 
>>
>> However, there is a clear reason why we are developing a full integration 
>> between Arches and esri–namely, the development has been financed. The 
>> effort is driven by Historic England because they use esri products 
>> widely, and they have kindly funded a significant piece of the development. 
>> (The remainder is financed by Farallon Geographics and us, the Getty 
>> Conservation Institute.)
>>
>> Our sincere hope in completing this work is, exactly as you suggest, that 
>> once the development patterns are established the work to integrate Arches 
>> with QGIS will be greatly facilitated...hopefully by someone very soon!
>>
>> Thanks for your candor, I really appreciate your feedback and hope that 
>> you continue to make your voice heard for the benefit of the community.
>>
>> Best,
>> Alison
>>
>> On Thursday, January 2, 2020 at 11:03:29 AM UTC-8, Alina Myklebust wrote:
>>>
>>> Hi David,
>>>
>>> Thanks so much for your feedback on the roadmap.  I imagine there will 
>>> be many discussions/conversations in the coming weeks/months about this new 
>>> ArcGIS
>>> integration development.   I'll ask others to chime in here too, because 
>>> I'm certain there have been thoughts and considerations related to 
>>> integration with QGIS too.  
>>>
>>> Thanks again and Happy New Year!  
>>>
>>> Very best,
>>>
>>> Alina
>>>
>>>
>>>
>>> On Tuesday, December 24, 2019 at 8:43:34 AM UTC-8, David Osborne wrote:

 Hi Alina

 The developments in the roadmap look interesting, especially, for me, 
 the science applications. However, I must admit disappointment that ArcGIS 
 has been chosen in preference to QGIS for the GIS interface. I expect 
 there 
 will be several projects which were attracted to Arches due to it being 
 free, open-source software and, like ours, have opted for QGIS for the 
 same 
 reason. However, my hope is that, once the team have developed the Arches 
 plugin for Arc, it will be possible to adapt it to interface with QGIS 
 without too much extra work.

 Kind regards
 David

 On Wednesday, 18 December 2019 22:41:33 UTC, Alina Myklebust wrote:
>
> Greetings all,
>
> This week we published an updated Arches Roadmap on the Arches Project 
> website.  You can find it here:  
> https://www.archesproject.org/roadmap/
>
> Visit the page to find out about new key development initiatives and 
> planned features & development work slated for 2020. 
>
> Roadmap highlights include: 
>
>- Arches for Science
>- Arches Workflows
>- Arches/esri integration 
>- Important upgrades in Version 5
>
> If you have any questions, please post them here.  Thanks!
>
>
> Cheers,
>
> Alina
> Arches Project Team
>


-- 
-- To post, send email to archesproject@googlegroups.com. To unsubscribe, send 
email to archesproject+unsubscr...@googlegroups.com. For more information, 
visit https://groups.google.com/d/forum/archesproject?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to archesproject+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/archesproject/f583e695-336f-4837-a6c7-a4bd37a18968%40googlegroups.com.

Re: [Arches] Re: Arches v5 in Docker - creating a Project

[Ashish Gautam]

Hi Markus,

I had a similar issue earlier while running Archesv5 in Docker. I did the
following changes to create and run custom-project smoothly:

1: entrypoint.sh file inside arches/docker/

  Entrypoint breaks while creating the custom-arches-project in the line:

[image: image.png]
remove line 221 and  --directory ${ARCHES_PROJECT}  from line 223. In order
to reflect these changes, you can bind mount this file inside the container
or build a new one. Note that this should run the container without any
issue only in DEV mode. If you want to run in PROD mode then more steps
are required which also depends on whether you want to run Celery or not.

Best Regards,
Ashish






On Thu, Jun 4, 2020 at 4:41 AM Markus S.  wrote:

> I got further by changing DJANGO_MODE=PROD to DJANGO_MODE=DEV. Now system
> starts up at least. It looks broken, though. The web server returns a 400
> error on a lot of the media files.
>
> Nevertheless, I am trying to do this with *v5*. The instructions at
> https://github.com/archesproject/arches/tree/master/docker#setting-up-your-own-arches-project
> are utilizing a *v4* Docker image. Swapping that to a v5 image did no
> work.
>
> I will continue exploring this.
>
> --
> -- To post, send email to archesproject@googlegroups.com. To unsubscribe,
> send email to archesproject+unsubscr...@googlegroups.com. For more
> information, visit https://groups.google.com/d/forum/archesproject?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Arches Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to archesproject+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/archesproject/41ac5f46-8e0c-45e6-aad8-bff1808c72e3%40googlegroups.com
> 
> .
>

-- 
-- To post, send email to archesproject@googlegroups.com. To unsubscribe, send 
email to archesproject+unsubscr...@googlegroups.com. For more information, 
visit https://groups.google.com/d/forum/archesproject?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to archesproject+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/archesproject/CAJ-3LxrVtiX_G%2BGhBX9bXAhsdWqsnDW0-4hWjO0e789g6QE%3DXg%40mail.gmail.com.