[talk-pr] Is there a negative consequence of removing POI nodes when a building polygon has been tagged with all relevant information

Sat Jan 18 19:27:39 UTC 2014

I played around with yet another option, converting the imagery into
MBtiles format, which would take less space than a regular tile directory
structure.  I think that pre-rendered to zoom 19, it could be done in
MBtiles in the realm of ~400GB.  But it would require a server app to serve
tiles, instead of just static storage.

The quality difference is immense.  Here's a comparison of NOAA imagery vs.
Bing in Vieques:

[image: Inline image 1]

[image: Inline image 2]

On Fri, Jan 17, 2014 at 1:15 PM, Jeff Haack <jeff.haack at gmail.com> wrote:

> This is awesome.  And metadata is perfect to ensure its public domain.  So
> no worries there.
>
> Here's the 09-10 imagery btw -
> ftp://csc.noaa.gov/pub/DigitalCoast/raster2/imagery/PuertoRico_2009_1421/
>
>
>
>
> On Fri, Jan 17, 2014 at 9:11 AM, Agustin Graterole <igeopr at gmail.com>wrote:
>
>> Hey if someone hasn't seen this imagery you can go to the second link on
>> the previous message (http://www.csc.noaa.gov/dataviewer/<http://www.csc.noaa.gov/dataviewer/index.html?action=advsearch&qType=in&qFld=id&datareg=1&qVal=1421#app=f8ce&8069-selectedIndex=0>).
>> This is for NOAA's web map. In there choose/check Imagery on the upper
>> right as a basemap. Now start zooming into Old San Juan as close as you can
>> and you'll see it. Side note, the imagery service NOAA is using on their
>> map is ESRI's, but specifically the imagery I just told to look is USACE's
>> one.
>>
>>
>> On Fri, Jan 17, 2014 at 8:51 AM, Agustin Graterole <igeopr at gmail.com>wrote:
>>
>>> Found Sources and Documentation for the 2009-10 orthoimagery.
>>>
>>>
>>>    - NOAA's base portal where you search for datasets:
>>>    http://www.csc.noaa.gov/digitalcoast/dataregistry/#/
>>>
>>>
>>>
>>>    - NOAA's web map app where you can download datasets (haven't tried
>>>    it):
>>>    http://www.csc.noaa.gov/dataviewer/index.html?action=advsearch&qType=in&qFld=id&datareg=1&qVal=1421#app=f8ce&8069-selectedIndex=0
>>>
>>>
>>>
>>>    - Metadata!!:
>>>    http://csc.noaa.gov/dataviewer/webfiles/metadata/2009_usace_pr.html#2
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jan 17, 2014 at 12:33 AM, Jeff Haack <jeff.haack at gmail.com>wrote:
>>>
>>>> Jose, if we host with Tilecache, I think we would need the size of the
>>>> geotiffs (~50GB according to other thread) + maybe 10-20 GB more for the
>>>> tiles.  The more the better I suppose, but I'm pretty sure Tilecache will
>>>> expire and remove tiles as space is needed, or at worst you could set up a
>>>> cron job to do it.
>>>>
>>>>
>>>> On Fri, Jan 17, 2014 at 12:28 AM, Jeff Haack <jeff.haack at gmail.com>wrote:
>>>>
>>>>> If all the tiles are prerendered I would expect a minimum of 2TB of
>>>>> data.  You can try it out with the GDAL library - you'll want gdal2tiles.py
>>>>> I believe.  I rendered the country of Georgia once, black and white imagery
>>>>> covering roughly 50,000 sq. km to zoom 18, and that was around 1.7TB in
>>>>> tiles.  Not sure but thinking Tilecache would be better option.
>>>>>
>>>>>
>>>>> On Thursday, January 16, 2014, Victor Ramirez <
>>>>> vramirez122000 at yahoo.com> wrote:
>>>>>
>>>>>> Just for reference, in Amazon S3, 200 GB of storage would cost around
>>>>>> $20 a month. How much data are we talking about?
>>>>>>
>>>>>> On 01/16/2014 05:33 PM, JOSE L CUEVAS wrote:
>>>>>> > I can try to setup a test-bed infrastructure at the university.
>>>>>>  Was thinking of MapServer with titlecache.  I have no experience with none
>>>>>> of them but will try to get something started. Any idea of how much space
>>>>>> we will need for the WMS data?
>>>>>> >
>>>>>> > On Jan 16, 2014, at 1:00 PM, Jeff Haack <jeff.haack at gmail.com>
>>>>>> wrote:
>>>>>> >
>>>>>> >> Search will work the same with points and polygons.  I believe it
>>>>>> is incorrect to have a point with identical information to a polygon,
>>>>>> better to use a polygon if you can draw it.  It seems common though to draw
>>>>>> a building and then put POIs as points within it when there are numerous
>>>>>> shops in the same building.
>>>>>> >>
>>>>>> >> Re: Marshall's, I don't think there is a common accepted standard
>>>>>> on this.  What I typically do is map the whole building as something if the
>>>>>> vast majority of it is taken up by one place, as is the case with
>>>>>> Marshall's.  But arguably it could be done with a POI too.
>>>>>> >>
>>>>>> >>
>>>>>> >> On Wed, Jan 15, 2014 at 9:46 PM, Victor Ramirez <
>>>>>> vramirez122000 at yahoo.com> wrote:
>>>>>> >> For example, would it affect the OSM search database?
>>>>>> >>
>>>>>> >> If a shop happens to be in a building, should the building name be
>>>>>> the name of the most prominent shop (e.g. mashalls old san juan)?
>>>>>> >>
>>>>>> >> _______________________________________________
>>>>>> >> talk-pr mailing list
>>>>>> >> talk-pr at openstreetmap.org
>>>>>> >> https://lists.openstreetmap.org/listinfo/talk-pr
>>>>>> >>
>>>>>> >>
>>>>>> >> _______________________________________________
>>>>>> >> talk-pr mailing list
>>>>>> >> talk-pr at openstreetmap.org
>>>>>> >> https://lists.openstreetmap.org/listinfo/talk-pr
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > talk-pr mailing list
>>>>>> > talk-pr at openstreetmap.org
>>>>>> > https://lists.openstreetmap.org/listinfo/talk-pr
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> talk-pr mailing list
>>>>>> talk-pr at openstreetmap.org
>>>>>> https://lists.openstreetmap.org/listinfo/talk-pr
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> talk-pr mailing list
>>>> talk-pr at openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-pr
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-pr/attachments/20140118/57a4ee9e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-01-18 at 3.14.26 PM.png
Type: image/png
Size: 486696 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-pr/attachments/20140118/57a4ee9e/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-01-18 at 3.14.34 PM.png
Type: image/png
Size: 274882 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-pr/attachments/20140118/57a4ee9e/attachment-0003.png>