Re: [OSM-talk] Map legends: Another option

[Lars Ahlzen]

Stefan Baebler wrote:
> It's nice seeing changing road width with zoom also in the legend!

Yep. True WYSIWYG. :)

> It would  be also interesting to hide features that are not appearing
> in the map currently being shown.
> Sure it would require a bbox query, but it would be much more user
> friendly (eg when matching 2 shades of green in a map to 5 shades in
> the legend) and it would also allow showing relevant POI icons
> OTOH new mappers should see also not yet existing features (as their
> palette of features to choose from) with links to wiki :)

Technically implementing that on a slippy map sounds tricky, but it's an
interesting idea. It would probably be useful for legends with many
features.

- Lars

-- 
Lars Ahlzen
l...@ahlzen.com

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

[OSM-talk] Potted plants vs. garden beds

[Iván Sánchez Ortega]

Hi all,

In the talk-es list, a question has been raised about these things:

http://www.flickr.com/photos/8171...@n04/3665245829/
http://www.flickr.com/photos/8171...@n04/3665221611/
http://www.flickr.com/photos/8171...@n04/3665245839/

Question is, would you call those ...

a) barrier=potted_plant
b) barrier=garden_bed
c) Some other stuff


Cheers,
-- 
--
Iván Sánchez Ortega 

- No por vivir la vida al limite eres ningún bicho raro.

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

Re: [OSM-talk] CanVec:CODE vs. CanVec:UUID -relevancy

[Matt Amos]

On Sat, Jun 27, 2009 at 11:35 AM, Dave Stubbs wrote:
> 2009/6/26 Sam Vekemans :
>> Hi all,
>> Im sending it out to everyone, as its of international significance when
>> dealing with bulk data.
>>
>> The 4 general tags
>> attribution=Natural Resources Canada
>> - tells the users what agency it came from (public/private)
>>
>> created_by=canvec2osm
>> - tell the user what program was used to create it. ... ie. blame me if the
>> script doesnt work or is wrong.
>>
>> source=CanVec_Import_2009
>> -tells the user what import project session it is ... ie. next year we might
>> do an import again for the updates.
>>
>> canvec:UUID=11CF43756692E5F4E0409C8467120387
>> - is the 'lot number / series and actual product identifier, more detailed
>> than the bar code (' which tells the user the identity of each node/way/area
>> they are looking at.
>>
>> The 5th, which is currently being debated
>> canvec:CODE=1200020
>> - This is the feature identifier, the SKU (Stock keeping unit) or the BIB
>> (Library catelogue number).  This tells the user which
>> Library/floor/section/shelf/book/page number that they are looking at.  When
>> the UUID identifies each character on the page.
>> Not having this CODE, would be like going to the library and asking if they
>> have a word in a book of 11CF43756692E5F4E0409C8467120387, when the CODE is
>> human-readable.  The 0 at the end means its a NODE a 1 - means a way and a 2
>> means an area. The 120 at the begining means it's part of the 129 series
>> of features.  and the '2' means it's the 2nd feature type in the set.
>> Like identifing 2 identical books, 'Times Atlas' where they has different
>> UUID's, but the same Catelogue code.
>>
>> So does anyone have objections to the logic and usefullness behind me
>> keeping canvec:CODE?  Or any arguments for/against what i wrote above?..
>> And at the same time im recommending for all imports that this gets added
>> (it its available).
>>
>
> Where are these tags going?
> Some definitely belong on changesets (there's no way
> source=CanVec_Import_2009 needs to be on every object when it's the
> same for everything you upload), whereas the UUID looks like it should
> be on the objects themselves.

+1

the attribution, source and created_by tags should definitely go on
the changeset, if possible.

the UUID might even be going too far. what happens when someone edits
a node with a UUID on it? is it still, for any useful purpose, the
same node?

> Also I'm a bit confused about what this CODE is. Is it about finding
> the feature, or about telling you what the feature is? If it's just
> what the feature is then it's possibly redundant. If it's about
> finding it, then is it likely to be the same for all elements of an
> upload? -- in which case it can also go on the changset.

+1

if CODE is common for each upload (or at least the non-feature-type
part of it) then it would save a lot of time, bandwidth and space to
put it on the changeset.

cheers,

matt

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

Re: [OSM-talk] CanVec:CODE vs. CanVec:UUID -relevancy

[Richard Weait]

On Fri, 2009-06-26 at 15:40 -0700, Sam Vekemans wrote:
[ ... a lot of stuff ... ]
> The 5th, which is currently being debated
> canvec:CODE=1200020
> - This is the [CanVec] feature identifier, [analogy removed].
> 
> So does anyone have objections to the logic and usefulness of
> canvec:CODE?  Or any arguments for/against what I wrote above?..  And
> at the same time I'm recommending for all imports that this gets added
> (if it is available). [edits for readability]

Sure, I object, Sam.  :-)  canvec:CODE only helps by making it easier
for somebody to go back to the CanVec data.  Ideally we want the data to
"just work" in OSM so that an external reference is rarely required.  

Object that you selected for your example is instructive and I see why
you are tempted to explain it further.  Let's have a look at a CanVec
1200020 object.  According to the wiki page[1] that you wrote based on
the CanVec docs, 1200020 is a cartographic spot height.  

Here's one from a sample area in southern Ontario











A "name" tag here is inappropriate.  The name of this survey point is
not "325", "325" is the elevation.

Use man_made=survey_point[2].  That will be in step with accepted OSM
usage, _and_ adds the context that helps OSM'ers decide how to use the
data.  

Best regards,
Richard


[1] http://wiki.openstreetmap.org/wiki/CanVec:_Relief_and_landforms_(FO)
[2] http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dsurvey_point


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

Re: [OSM-talk] Changeset history - hide 'big' edits?

[Matt Amos]

2009/6/27 Iván Sánchez Ortega :
> El Sábado, 27 de Junio de 2009, Dirk-Lüder Kreie escribió:
>> Where big edit = bbox is larger what the API would allow in a map call?
>> +1
>
> +1
>
> Would it be possible for the API* (or the editors) to split up big changesets
> in bboxes that size?

maybe instead of (or as well as) changesets having bboxes they could
have a "footprint" - a set of touched quadtiles or something. this
would be much faster to query, i guess.

as an experiment, this could already be done by a 3rd party site
looking at the diff stream, so there's no real need to do it on the
main server(s) just yet.

on the other hand, the editors could easily do it themselves :-)

cheers,

matt

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

Re: [OSM-talk] Adding OpenStreetMap map into wordpress.com post

[Inge Wallin]

On Thursday 25 June 2009 16:37:14 andrzej zaborowski wrote:
> 2009/6/25 John Smith :
> > --- On Thu, 25/6/09, Vincent MEURISSE  wrote:
> >> >> and cannot install the OSM plugin for
> >> >> wordpress neither
> >> >
> >> > http://wordpress.org/extend/plugins/osm/
> >>
> >> ??
> >> nice answer :)
> >>
> >> (Btw I don't know the answer)
> >
> > Take a screen shot?
>
> Since the goal is to replace Google maps it should have the same
> functionality.  While I don't know the answer I suggest looking at how
> the Google maps worked, if it was using a wordpress plugin then it
> should be equally doable with the osm plugin (what's the error
> message, if there's one?).

You may get bigger acceptance for the idea of using OSM instead of Google if 
you point out places where OSM is much, much better.  Case in point:
http://tools.geofabrik.de/mc/?mt0=googlemap&mt1=mapnik&lon=26.0527&lat=44.40828&zoom=11
 
(Bukarest -- in fact most of Romania)

-Inge


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

Re: [OSM-talk] Map legends: Another option

[Ævar Arnfjörð Bjarmason]

On Fri, Jun 26, 2009 at 11:17 PM, Lars Ahlzen wrote:
> Hi All,
>
> I know that there's been some talk about generating map legends/keys
> lately, and I don't know if there's a need for another option. It
> generated some interest when I mentioned it in my diary recently, however...
>
> I created a python script that generates an HTML legend (with images)
> based on a description of features to be included and one or more Mapnik
> XML configuration files. Thus, I can automatically generate legends for
> each zoom level of my map. If I modify the map style, I can just run the
> script again.
>
> Example at: http://toposm.com/ma/
>
> (click on "Show/Hide Legend" at the bottom right). It's dynamic, so it
> will reload when you zoom in and out.
>
> It was created for the TopOSM project, but it may be useful to other
> projects that use Mapnik for rendering.
>
> The script itself, and more info, is available at:
>
> http://wiki.openstreetmap.org/wiki/TopOSM#Map_legend

It would be neat if someone modified this to make it generate a legend
for the main web interface.

It's not that hard, here's an example of an entry for osmarender being added:

http://trac.openstreetmap.org/changeset/16132

The "motorway" key is then used to look up a translation, e.g.:

http://trac.openstreetmap.org/browser/sites/rails_port/config/locales/en.yml#L581

Of course if you were going to modify it to have sections as in that
example you'd have to add section heading generation to the code, but
that shouldn't be that hard.

The main thing that needs to be done is to make something that can
read the main mapnik stylesheet and spit out something machine
readable that indicates what zoom level that feature is visible on, a
path to an associated PNG file, and optionally what section (e.g.
Roads) it's under.

Looks like this is mostly done at TopOSM, it's just a matter of
someone doing the needed integration legwork.

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

Re: [OSM-talk] SOTM 08 videos

[Ivan Garcia]

Hi Andy, maybe you can download those that are in the site and transcode
them in an smaller size, or upload them into iwkimedia for streaming.

The videos only show the saturday 12, what about sunday 13th ?

Best Regards.
Ivan.

On Thu, Jun 18, 2009 at 12:00 PM, Andy Allan  wrote:

> On Wed, Jun 17, 2009 at 9:46 PM, SteveC wrote:
> > Hi
> >
> > Linked off of stateofthemap.org are the SOTM '08 videos:
> >
> >
> > http://blog.signal2noise.ie/~eason/sotm08/
> >
> > But they're incomplete and super, super, super slow to load.
> >
> > So does anyone know if the rest will be put up?
>
> I've offered assistance with this a few times over the last year, but
> so far to no avail. I'm keen to help with whatever needs doing - I
> have a postal address (for DVDs, tapes or whatnot), a computer capable
> of transcoding, a fast internet pipe and hosting and I'm willing to
> sort out all the videos if it means my own one sees the light of day.
>
> So whoever (eason?) has the originals now, feel free to contact me.
>
> Cheers,
> Andy
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] CanVec:CODE vs. CanVec:UUID -relevancy

[Dave Stubbs]

2009/6/26 Sam Vekemans :
> Hi all,
> Im sending it out to everyone, as its of international significance when
> dealing with bulk data.
>
> The 4 general tags
> attribution=Natural Resources Canada
> - tells the users what agency it came from (public/private)
>
> created_by=canvec2osm
> - tell the user what program was used to create it. ... ie. blame me if the
> script doesnt work or is wrong.
>
> source=CanVec_Import_2009
> -tells the user what import project session it is ... ie. next year we might
> do an import again for the updates.
>
> canvec:UUID=11CF43756692E5F4E0409C8467120387
> - is the 'lot number / series and actual product identifier, more detailed
> than the bar code (' which tells the user the identity of each node/way/area
> they are looking at.
>
> The 5th, which is currently being debated
> canvec:CODE=1200020
> - This is the feature identifier, the SKU (Stock keeping unit) or the BIB
> (Library catelogue number).  This tells the user which
> Library/floor/section/shelf/book/page number that they are looking at.  When
> the UUID identifies each character on the page.
> Not having this CODE, would be like going to the library and asking if they
> have a word in a book of 11CF43756692E5F4E0409C8467120387, when the CODE is
> human-readable.  The 0 at the end means its a NODE a 1 - means a way and a 2
> means an area. The 120 at the begining means it's part of the 129 series
> of features.  and the '2' means it's the 2nd feature type in the set.
> Like identifing 2 identical books, 'Times Atlas' where they has different
> UUID's, but the same Catelogue code.
>
> So does anyone have objections to the logic and usefullness behind me
> keeping canvec:CODE?  Or any arguments for/against what i wrote above?..
> And at the same time im recommending for all imports that this gets added
> (it its available).
>

Where are these tags going?
Some definitely belong on changesets (there's no way
source=CanVec_Import_2009 needs to be on every object when it's the
same for everything you upload), whereas the UUID looks like it should
be on the objects themselves.

Also I'm a bit confused about what this CODE is. Is it about finding
the feature, or about telling you what the feature is? If it's just
what the feature is then it's possibly redundant. If it's about
finding it, then is it likely to be the same for all elements of an
upload? -- in which case it can also go on the changset.

Dave

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

Re: [OSM-talk] Map legends: Another option

[Ulf Lamping]

Stefan Baebler schrieb:
> It's nice seeing changing road width with zoom also in the legend!
> 
> It would  be also interesting to hide features that are not appearing
> in the map currently being shown.
> Sure it would require a bbox query, but it would be much more user
> friendly (eg when matching 2 shades of green in a map to 5 shades in
> the legend) and it would also allow showing relevant POI icons
> OTOH new mappers should see also not yet existing features (as their
> palette of features to choose from) with links to wiki :)

It's nice seeing improvements in the map legends :-)

Hiding the "currently not available" features from the legend has a 
drawback: You don't know which features are generally available at this 
specific map zoomlevel, and which are just not existing in the currently 
shown bbox.

I agree that it would be nice to distinguish it though. Maybe specially 
marking it with a different background color or such might be an idea.


Anyway, to all involved: Keep up the good key/legend work, another 
example where OSM makes a difference :-)))

Regards, ULFL

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