Re: [Tagging] Width of shop frontage

2010-11-23 Thread Laurence Penney
On 23 Nov 2010, at 05:47, Steve Bennett wrote:

 On Tue, Nov 23, 2010 at 7:57 AM, Laurence Penney l...@lorp.org wrote:
 I think it would be particularly useful to demonstrate that the whole of a 
 row of shops has been surveyed. After taking account of the units tag, any 
 gaps in a line of nodes - on a fully surveyed street - could be taken to be 
 private houses or empty space.
 
 If that's the most compelling use case, surely there are more direct
 ways of indicating this, like a note=*? I can't see how a renderer
 could ever make use of the units=* tag, so it's essentially only for
 other mappers anyway?

I am indeed thinking of other mappers rather than renderers.

One reason I'd like it in a predictable place (either units=* or width=*) is to 
facilitate an app whose purpose is to populate all the shops along a street.

For example, it would be nice to gather all the shops along Oxford Street:

http://www.openstreetmap.org/?lat=51.514746lon=-0.146429zoom=18layers=M

My imagined app would first work out what street one was walking along using 
GPS. Let's say it determined you were walking east along Oxford Street. It 
would then divide the area around you into segments:

* North side: Marylebone Lane to Vere Street
* North side: Vere Street to Chapel Place
* North side: Chapel Place to Old Cavendish Street
* South side: Sedley Street to Woodstock Street
* South side: Woodstock Street to New Bond Street
* South side: New Bond Street to Dering Street

It would detect (or ask you to declare) which segment you are in, and then 
suggest you add POIs for all the shops by presenting a list of blank slots. It 
might start off with a default ~7m shop unit width, adjusting the 
width-per-unit as more nodes are placed into the space. Declaring a shop as 
width=2 units would get the node placed in the middle.

Here's a before  after:


|-- SS2
|
|
|
M
|
|
|
|-- SS1
|

Let's say, as you walk north up road M, the app determines there are 7 shop 
units available between sidestreet SS1 and sidestreet SS2. It presents 7 input 
boxes for you (prefilling some with any shop POIs found).

|-- SS2
| N5
| 
| N4
M 
| N3
| N2
| N1
|-- SS1
|

Here's the same street after I've walked up it, filling in 5 of the 7 boxes 
with shop POIs (marked N1..N5). For shop N4, I've declared width=3 units 
(perhaps by dragging an input box larger in the app's UI), so the node is 
placed in the middle of the space it takes up on the ground.

Regarding using addr:housenumber for this, it's not going to work where the 
numbers increase non-linearly, which is nearly everywhere. Also won't work 
where the large buildings (which might be themselves 3 or 5 shop units wide) 
have numbers. Shopping malls are problematic too - the numbers for the shop 
units are often difficult to find out. I'd also like to map half-units and 
one-third-units, which are quite common - and share a housenumber.

Regarding using the building outline, I'm not convinced it's useful to add 
buildings where you cannot see the back.

One cool thing about such an app would be that its main UI would not be a map, 
just a list of input boxes. Mobile mappers would NOT be placing dots on maps - 
something I've tried (and hate) with Mapzen POI Collector. Having a 2D UI for 
this kind of POI placement is suboptimal! The two dimensions of node location, 
which needless to say are easily converted to latlong, are: interpolation 
between sidestreet junctions with the main street, and a default distance of 
shop frontage from road centre with override.

I can't think of any quicker way to survey entire streets of shops into OSM. Is 
anyone else interested in developing such an app?

- L


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Width of shop frontage

2010-11-23 Thread Laurence Penney
Thanks for the feedback.

It doesn't matter if the unit width varies from street to street - it's a folk 
measure, not a metric measure. The principal benefit is, when the streets are 
already mapped, to be able to walk down a street typing 100 names into boxes, 
rather than positioning 100 nodes in 2D (and also then typing their names). In 
other words, it's a method for automatic node positioning.

Does this make the concept clearer?

- L

On 23 Nov 2010, at 16:43, Peter Wendorff wrote:

 Hi.
 I understand your sketch of how-to-map-the-shops; but What's the real benefit?
 If there are the value for a shop-width-unit in OSM already, someone worked 
 that out in the past - why shouldn't he add the individual nodes for the 
 shops instead of helping other mappers to do it later?
 The usual case will be, that this unit is different at least from streat to 
 streat; often perhaps from street segment to street segment.
 
 That in mind I don't think it's really useful.
 There ARE already mechanisms to divide housenumber-interpolations to 
 individual nodes (e.g. in JOSM) for an estimated positioning of these.
 
 regards
 Peter
 
 Am 23.11.2010 16:23, schrieb Laurence Penney:
 On 23 Nov 2010, at 05:47, Steve Bennett wrote:
 
 On Tue, Nov 23, 2010 at 7:57 AM, Laurence Penneyl...@lorp.org  wrote:
 I think it would be particularly useful to demonstrate that the whole of a 
 row of shops has been surveyed. After taking account of the units tag, any 
 gaps in a line of nodes - on a fully surveyed street - could be taken to 
 be private houses or empty space.
 If that's the most compelling use case, surely there are more direct
 ways of indicating this, like a note=*? I can't see how a renderer
 could ever make use of the units=* tag, so it's essentially only for
 other mappers anyway?
 I am indeed thinking of other mappers rather than renderers.
 
 One reason I'd like it in a predictable place (either units=* or width=*) is 
 to facilitate an app whose purpose is to populate all the shops along a 
 street.
 
 For example, it would be nice to gather all the shops along Oxford Street:
 
 http://www.openstreetmap.org/?lat=51.514746lon=-0.146429zoom=18layers=M
 
 My imagined app would first work out what street one was walking along using 
 GPS. Let's say it determined you were walking east along Oxford Street. It 
 would then divide the area around you into segments:
 
 * North side: Marylebone Lane to Vere Street
 * North side: Vere Street to Chapel Place
 * North side: Chapel Place to Old Cavendish Street
 * South side: Sedley Street to Woodstock Street
 * South side: Woodstock Street to New Bond Street
 * South side: New Bond Street to Dering Street
 
 It would detect (or ask you to declare) which segment you are in, and then 
 suggest you add POIs for all the shops by presenting a list of blank slots. 
 It might start off with a default ~7m shop unit width, adjusting the 
 width-per-unit as more nodes are placed into the space. Declaring a shop as 
 width=2 units would get the node placed in the middle.
 
 Here's a before  after:
 
 
 |-- SS2
 |
 |
 |
 M
 |
 |
 |
 |-- SS1
 |
 
 Let's say, as you walk north up road M, the app determines there are 7 shop 
 units available between sidestreet SS1 and sidestreet SS2. It presents 7 
 input boxes for you (prefilling some with any shop POIs found).
 
 |-- SS2
 | N5
 |
 | N4
 M
 | N3
 | N2
 | N1
 |-- SS1
 |
 
 Here's the same street after I've walked up it, filling in 5 of the 7 boxes 
 with shop POIs (marked N1..N5). For shop N4, I've declared width=3 units 
 (perhaps by dragging an input box larger in the app's UI), so the node is 
 placed in the middle of the space it takes up on the ground.
 
 Regarding using addr:housenumber for this, it's not going to work where the 
 numbers increase non-linearly, which is nearly everywhere. Also won't work 
 where the large buildings (which might be themselves 3 or 5 shop units wide) 
 have numbers. Shopping malls are problematic too - the numbers for the shop 
 units are often difficult to find out. I'd also like to map half-units and 
 one-third-units, which are quite common - and share a housenumber.
 
 Regarding using the building outline, I'm not convinced it's useful to add 
 buildings where you cannot see the back.
 
 One cool thing about such an app would be that its main UI would not be a 
 map, just a list of input boxes. Mobile mappers would NOT be placing dots on 
 maps - something I've tried (and hate) with Mapzen POI Collector. Having a 
 2D UI for this kind of POI placement is suboptimal! The two dimensions of 
 node location, which needless to say are easily converted to latlong, are: 
 interpolation between sidestreet junctions with the main street, and a 
 default distance of shop frontage from road centre with override.
 
 I can't think of any quicker way to survey entire streets of shops into OSM. 
 Is anyone else interested in developing such an app?
 
 - L
 
 
 

Re: [Tagging] Width of shop frontage

2010-11-23 Thread john
How will it handle multiple businesses sharing the same street address?  A 
common pattern in the USA is for all of the offices/stores in a shared building 
to have the same street address but have different suite numbers (for example, 
123 Main Street, suite 101; and 123 Main Street, Suite 102).  It is common for 
these offices/storefronts to vary in size, within the same building.

---Original Email---
Subject :Re: [Tagging] Width of shop frontage
From  :mailto:l...@lorp.org
Date  :Tue Nov 23 13:31:57 America/Chicago 2010


Thanks for the feedback.

It doesn't matter if the unit width varies from street to street - it's a folk 
measure, not a metric measure. The principal benefit is, when the streets are 
already mapped, to be able to walk down a street typing 100 names into boxes, 
rather than positioning 100 nodes in 2D (and also then typing their names). In 
other words, it's a method for automatic node positioning.

Does this make the concept clearer?

- L

On 23 Nov 2010, at 16:43, Peter Wendorff wrote:

 Hi.
 I understand your sketch of how-to-map-the-shops; but What's the real benefit?
 If there are the value for a shop-width-unit in OSM already, someone worked 
 that out in the past - why shouldn't he add the individual nodes for the 
 shops instead of helping other mappers to do it later?
 The usual case will be, that this unit is different at least from streat to 
 streat; often perhaps from street segment to street segment.
 
 That in mind I don't think it's really useful.
 There ARE already mechanisms to divide housenumber-interpolations to 
 individual nodes (e.g. in JOSM) for an estimated positioning of these.
 
 regards
 Peter
 
 Am 23.11.2010 16:23, schrieb Laurence Penney:
 On 23 Nov 2010, at 05:47, Steve Bennett wrote:
 
 On Tue, Nov 23, 2010 at 7:57 AM, Laurence Penneyl...@lorp.org  wrote:
 I think it would be particularly useful to demonstrate that the whole of a 
 row of shops has been surveyed. After taking account of the units tag, any 
 gaps in a line of nodes - on a fully surveyed street - could be taken to 
 be private houses or empty space.
 If that's the most compelling use case, surely there are more direct
 ways of indicating this, like a note=*? I can't see how a renderer
 could ever make use of the units=* tag, so it's essentially only for
 other mappers anyway?
 I am indeed thinking of other mappers rather than renderers.
 
 One reason I'd like it in a predictable place (either units=* or width=*) is 
 to facilitate an app whose purpose is to populate all the shops along a 
 street.
 
 For example, it would be nice to gather all the shops along Oxford Street:
 
 http://www.openstreetmap.org/?lat=51.514746lon=-0.146429zoom=18layers=M
 
 My imagined app would first work out what street one was walking along using 
 GPS. Let's say it determined you were walking east along Oxford Street. It 
 would then divide the area around you into segments:
 
 * North side: Marylebone Lane to Vere Street
 * North side: Vere Street to Chapel Place
 * North side: Chapel Place to Old Cavendish Street
 * South side: Sedley Street to Woodstock Street
 * South side: Woodstock Street to New Bond Street
 * South side: New Bond Street to Dering Street
 
 It would detect (or ask you to declare) which segment you are in, and then 
 suggest you add POIs for all the shops by presenting a list of blank slots. 
 It might start off with a default ~7m shop unit width, adjusting the 
 width-per-unit as more nodes are placed into the space. Declaring a shop as 
 width=2 units would get the node placed in the middle.
 
 Here's a before  after:
 
 
 |-- SS2
 |
 |
 |
 M
 |
 |
 |
 |-- SS1
 |
 
 Let's say, as you walk north up road M, the app determines there are 7 shop 
 units available between sidestreet SS1 and sidestreet SS2. It presents 7 
 input boxes for you (prefilling some with any shop POIs found).
 
 |-- SS2
 | N5
 |
 | N4
 M
 | N3
 | N2
 | N1
 |-- SS1
 |
 
 Here's the same street after I've walked up it, filling in 5 of the 7 boxes 
 with shop POIs (marked N1..N5). For shop N4, I've declared width=3 units 
 (perhaps by dragging an input box larger in the app's UI), so the node is 
 placed in the middle of the space it takes up on the ground.
 
 Regarding using addr:housenumber for this, it's not going to work where the 
 numbers increase non-linearly, which is nearly everywhere. Also won't work 
 where the large buildings (which might be themselves 3 or 5 shop units wide) 
 have numbers. Shopping malls are problematic too - the numbers for the shop 
 units are often difficult to find out. I'd also like to map half-units and 
 one-third-units, which are quite common - and share a housenumber.
 
 Regarding using the building outline, I'm not convinced it's useful to add 
 buildings where you cannot see the back.
 
 One cool thing about such an app would be that its main UI would not be a 
 map, just a list of input boxes. Mobile mappers would NOT 

Re: [Tagging] Width of shop frontage

2010-11-23 Thread Laurence Penney
Could work really well: fill in the address for the first shop, it gets 
prefilled (maybe housenumber preinc/decremented) for the next shop.

Or mappers can leave addressing to a separate survey.

- L

On 23 Nov 2010, at 20:08, j...@jfeldredge.com wrote:

 How will it handle multiple businesses sharing the same street address?  A 
 common pattern in the USA is for all of the offices/stores in a shared 
 building to have the same street address but have different suite numbers 
 (for example, 123 Main Street, suite 101; and 123 Main Street, Suite 102).  
 It is common for these offices/storefronts to vary in size, within the same 
 building.
 
 ---

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging