User:Darija Medic/Documentation of Process: Difference between revisions

From XPUB & Lens-Based wiki
No edit summary
 
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[File:Oilfinish.jpg|800px]]
[[File:Oilfinish.jpg|800px]]


http://upload.wikimedia.org/wikipedia/commons/4/45/Dijksta_Anim.gif


http://trac.navit-project.org/ticket/456
20:30 < Shred00> so a reasonable fall back is being able to take an estimate based on the speed you hope to drive on certain types of roads.
20:30 < curious> yeah, but point is... calculating ETA is damn complex , and should be quite external from navit because
20:31 < curious> navit does NOT block way for such software
20:31 < curious> it allows live updates of map state
20:31 < curious> and this is quite enough
20:31 < Shred00> so, is there some documentation on this "external" interface?
20:31 < curious> read on 'traffic distortion'
20:32 < curious> there is no 'interface' - you provide just distortion.txt file which is included when re-calculating route
20:32 < curious> it can include all way of distortions
change of axis?
<source lang="c">
if (dx*sx > dy*sy)
d=dx*sx;
else
d=dy*sy;
m=d*rel/100+abs;
sel->u.c_rect.lu.x-=m;
sel->u.c_rect.rl.x+=m;
sel->u.c_rect.lu.y+=m;
sel->u.c_rect.rl.y-=m;
sel->next=NULL;
return sel;
</source>
modification of main menu?
gui_internal.c
<source lang="c">
231 struct gui_priv {
232 struct navit *nav;
233 struct attr self;
234 struct window *win;
235 struct graphics *gra;
236 struct graphics_gc *background;
237 struct graphics_gc *background2;
238 struct graphics_gc *highlight_background;
239 struct graphics_gc *foreground;
240 struct graphics_gc *text_foreground;
241 struct graphics_gc *text_background;
242 struct color background_color, background2_color, text_foreground_color, text_background_color;
243 int spacing;
244 int font_size;
245 int fullscreen;
246 struct graphics_font *fonts[3];
</source>
In route.c
<source lang="c">
/* HACK :) chnged behviour of routing lgorithm to prefer rod-segments of  certin length */
return ((int)sqrtf(powf(over->len - OPTIMUM_LEN, 2)))*36/speed+(dist ? dist->delay : 0);
</source>
in route.c
change to if new >s
<source lang="c">
if (new < s->end->value) { /* We've found a less costly way to reach the end of s, update it */
while (s) { /* Doing the same as above with the segments leading towards our point */
val=route_value_seg(profile, p_min, s, 1);
if (val != INT_MAX && !item_is_equal(s->data.item,p_min->seg->data.item)) {
new=min+val;
if (debug_route)
printf("end %d len %d vs %d (0x%x,0x%x)\n",new,val,s->start->value,s->start->c.x, s->start->c.y);
if (new < s->start->value) {
</source>
<source lang="bash">
#!/usr/bin/bash
    grep --color cost *.c
route.c: * point and segment a "value" which represents the "costs" of traveling from this point to the
route.c:   *  least costs */
route.c: int value; /**< The cost at which one can reach the destination from this point on */
route.c: * @brief Returns the "costs" of driving from point from over segment over in direction dir
route.c: * @return The "costs" needed to drive len on item
route.c: * @brief Calculates the routing costs for each point
route.c: * cost at which one can reach the destination from this point on. Additionally it assigns
route.c: * stated costs.
route.c: struct fibheap *heap; /* This heap will hold all points with "temporarily" calculated costs */
route.c: p_min=fh_extractmin(heap); /* Starting Dijkstra by selecting the point with the minimum costs on the heap */
route.c: if (! p_min) /* There are no more points with temporarily calculated costs, Dijkstra has finished */
route.c: if (new < s->end->value) { /* We've found a less costly way to reach the end of s, update it */
route.c: while (s && !dstinfo) { /* following start->seg, which indicates the least costly way to reach our destination */
sunriset.c:            double cost;
sunriset.c:            cost = ( sind(altit) - sind(lat) * sind(sdec) ) /
sunriset.c:            if ( cost >= 1.0 )
sunriset.c:            else if ( cost <= -1.0 )
sunriset.c:                  t = acosd(cost)/15.0;  /* The diurnal arc, hours */
sunriset.c:            double cost;
sunriset.c:            cost = ( sind(altit) - sind(lat) * sin_sdecl ) /
sunriset.c:            if ( cost >= 1.0 )
sunriset.c:            else if ( cost <= -1.0 )
sunriset.c:            else  t = (2.0/15.0) * acosd(cost); /* The diurnal arc, hours */
</source>
http://code.activestate.com/recipes/119466-dijkstras-algorithm-for-shortest-paths/
http://users.softlab.ece.ntua.gr/~ttsiod/python.html


== Links ==
== Links ==
[http://www.emfnews.org/ emf news]
[http://www.emfnews.org/testimonials.html testimonials]
[http://www.krugism.com/default.aspx ghost emf detector]
[http://stackoverflow.com/questions/2352679/passing-gps-lonlat-from-android-gps-to-webpage-javascript gps data from android]
[http://stackoverflow.com/questions/2707501/how-to-send-gps-data-from-android-to-a-website -||-]
[http://newtstuff.blogspot.com/2011/03/gps-chaos-how-30-box-can-jam-your-life.html GPS blocker]
[http://newtstuff.blogspot.com/2011/03/gps-chaos-how-30-box-can-jam-your-life.html GPS blocker]



Latest revision as of 09:46, 8 June 2011

Oilfinish.jpg

Dijksta_Anim.gif

http://trac.navit-project.org/ticket/456


20:30 < Shred00> so a reasonable fall back is being able to take an estimate based on the speed you hope to drive on certain types of roads.

20:30 < curious> yeah, but point is... calculating ETA is damn complex , and should be quite external from navit because

20:31 < curious> navit does NOT block way for such software

20:31 < curious> it allows live updates of map state

20:31 < curious> and this is quite enough

20:31 < Shred00> so, is there some documentation on this "external" interface?

20:31 < curious> read on 'traffic distortion'

20:32 < curious> there is no 'interface' - you provide just distortion.txt file which is included when re-calculating route

20:32 < curious> it can include all way of distortions


change of axis?

	if (dx*sx > dy*sy) 
		d=dx*sx;
	else
		d=dy*sy;
	m=d*rel/100+abs;
	sel->u.c_rect.lu.x-=m;
	sel->u.c_rect.rl.x+=m;
	sel->u.c_rect.lu.y+=m;
	sel->u.c_rect.rl.y-=m;
	sel->next=NULL;
	return sel;


modification of main menu?

gui_internal.c

231 	struct gui_priv {
232 	struct navit *nav;
233 	struct attr self;
234 	struct window *win;
235 	struct graphics *gra;
236 	struct graphics_gc *background;
237 	struct graphics_gc *background2;
238 	struct graphics_gc *highlight_background;
239 	struct graphics_gc *foreground;
240 	struct graphics_gc *text_foreground;
241 	struct graphics_gc *text_background;
242 	struct color background_color, background2_color, text_foreground_color, text_background_color;
243 	int spacing;
244 	int font_size;
245 	int fullscreen;
246 	struct graphics_font *fonts[3];


In route.c


/* HACK :) chnged behviour of routing lgorithm to prefer rod-segments of  certin length */
	return ((int)sqrtf(powf(over->len - OPTIMUM_LEN, 2)))*36/speed+(dist ? dist->delay : 0);

in route.c change to if new >s


if (new < s->end->value) { /* We've found a less costly way to reach the end of s, update it */


		while (s) { /* Doing the same as above with the segments leading towards our point */
			val=route_value_seg(profile, p_min, s, 1);
			if (val != INT_MAX && !item_is_equal(s->data.item,p_min->seg->data.item)) {
				new=min+val;
				if (debug_route)
					printf("end %d len %d vs %d (0x%x,0x%x)\n",new,val,s->start->value,s->start->c.x, s->start->c.y);
if (new < s->start->value) {


#!/usr/bin/bash

     grep --color cost *.c
route.c: * point and segment a "value" which represents the "costs" of traveling from this point to the
route.c:										  *  least costs */
route.c:	int value;							 /**< The cost at which one can reach the destination from this point on */
route.c: * @brief Returns the "costs" of driving from point from over segment over in direction dir
route.c: * @return The "costs" needed to drive len on item
route.c: * @brief Calculates the routing costs for each point
route.c: * cost at which one can reach the destination from this point on. Additionally it assigns
route.c: * stated costs.
route.c:	struct fibheap *heap; /* This heap will hold all points with "temporarily" calculated costs */
route.c:		p_min=fh_extractmin(heap); /* Starting Dijkstra by selecting the point with the minimum costs on the heap */
route.c:		if (! p_min) /* There are no more points with temporarily calculated costs, Dijkstra has finished */
route.c:				if (new < s->end->value) { /* We've found a less costly way to reach the end of s, update it */
route.c:	while (s && !dstinfo) { /* following start->seg, which indicates the least costly way to reach our destination */
sunriset.c:            double cost;
sunriset.c:            cost = ( sind(altit) - sind(lat) * sind(sdec) ) /
sunriset.c:            if ( cost >= 1.0 )
sunriset.c:            else if ( cost <= -1.0 )
sunriset.c:                  t = acosd(cost)/15.0;   /* The diurnal arc, hours */
sunriset.c:            double cost;
sunriset.c:            cost = ( sind(altit) - sind(lat) * sin_sdecl ) /
sunriset.c:            if ( cost >= 1.0 )
sunriset.c:            else if ( cost <= -1.0 )
sunriset.c:            else  t = (2.0/15.0) * acosd(cost); /* The diurnal arc, hours */

http://code.activestate.com/recipes/119466-dijkstras-algorithm-for-shortest-paths/ http://users.softlab.ece.ntua.gr/~ttsiod/python.html

Links

emf news

testimonials

ghost emf detector

gps data from android

-||-

GPS blocker

cell phone blocker

http://educ.ubc.ca/courses/etec540/Sept07/macdonaldd/commentary1/index_files/

http://www.hentges.net/irclogs/%23navit/2011/March/20110307_navit.log

  • Updated the TomTom software on TomTom Home
  • For using OSM, in the navit.xml map section map type has to be modified

with either the exact name or *.bin

March

27.3.2011. Meeting with Fawn Ellis, student from TU Delft, who does research on user behavior and the relation between people and interfaces, in the broadest sense. Research of this type is conducted in order to solve usability problems, and see how people feel when in direct contact with an interface, in order to improve design. In this research, people are either asked specific questions, or left to freely experience an interface, and afterwards asked how was there experience, what did they feel and why. It is important to have consistent groups ans ask consistent questions, not based on assumptions. From her experience the best people to test products on are the ones who have no experience. The ultimate goal of usability is offering people the feeling of control.


The most recent problem with Navit on my TomTom go 300 is the failure of loading maps, which cannot seem to be solved


February

Compiling Navit on TomTom go 300.



January

The decision to use a GPS device, and not a mobile phone came from the distinction between the two devices, the first being a multi-purpose entity, and the other serving as a device for a specific cause, diverse applications for phones are being built every day, and the gps device is closed source in more ways, because it has one purpose, to lead the fastest way from point a to point b, it is direct, useful, beneficial, it is an orientation and guide to completely surrender to (it is not interrupted by anything other than the lack of connection to a satellite)

Notes from tutorial November 8, 2010.

Before the tutorial with aymeric, I was considering the different interests that I have, and how to clarify what are the places where magical thinking comes into place in relation to technology, also which subjects am I particularly interested in. One approach would be observing elements of magical belief and elements of technological usage, finding the possible common points.


Things to use when writing:

  • Describe the project and the desired outcome
  • describe some previous projects
  • describe what you want to do
  • describe why you want to do it
  • describe how you intend to achieve it
  • describe the success criteria for this project


October

If I focus on new magical thinking, or a magical understanding of technology, the goal of this project would be to try and find a way of implementing it into my interest of navigating through information layers in the city.

Some things to look at:

cloud as a metaphor for mystifying data

tantalum chemical components in devices

i-phone suicides

Graham Harwood and his work on hardware energy


"The internet space, or the interactive space becomes so fractal, that we see things working on one level, that are self similar on the next level and self similar on the level after that. So once experienced in learning in a viral space, on a genuinely memetic viral space, a self similar space, is no longer through the traditional teaching stories of the Bible. We communicate through pattern recognition, rather than through teaching stories" Douglas Rushkof


September

Keywords: paranoia, procrastination, wild-domesticated, intuitive technology, spam, how does technology implement in popular culture, self referentiality, theories of conspiracy, vocabularies, concept of keywords, skyping, filtering, the Internet of things


Starting ideas:

Possible continuation of working with locative media in city spaces (the not realized element of my third thematic project), researching how does information shape spaces, and how do these layers of information communicate with space and with each other. How do we navigate through physical information?

animal-human-city how are animals perceived, what happens when the city is perceived as their natural habitat, antropomorphizateion of animals (pets), what belongs to "the wild", and what is "domesticated" in human-animal behavior. Where is the space of animals and who claims what. animal as meat, people as animals.

procrastinometer-a tool for measuring anxiety, unproductivity and frustration in today's working and living environment. How are our health and sanity affected by the shift of the working space


in combat with online semantics software that measures key markers in, for example, youtube videos, through speech recognition -prototype of a good internet citizen -customizing vocabularies of browsing



== literature: ==


The Internet of things-Rob Van Kranenburg,Insitute of Network Cultures, Amsterdam, 2008.

http://www.wired.com/medtech/health/magazine/16-05/ff_wozniak#,

Purity and danger-Mary Douglas, Routledge, 1966.

Sensorium. Embodied Experience, Technology, and Contemporary Art, edited by Caroline A. Jones,

Future shock,The third wave Powershift, alvin Toffler, Bantam books, New York, 1980.

Information feudalism, Peter Drahos with John Braithwaite, Earthscan, London, 2002.

On domesticated glitches, human wetware, on reality as mediated, as opposed to reality perceived as natural: GltchLnguistx: The Machine in the Ghost / Static Trapped in Mouths, Curt Cloninger Nictoglobe, Amsterdam, 2010 http://nictoglobe.com/new/query2.html?d=articles&f=glitch


other links

http://www.we-make-money-not-art.com/archives/2010/09/subverting-the-lidar-landscape.php,

http://www.museumofhoaxes.com/hoax/weblog/comments/animal_candidates/,

http://world-information.org/trd/intro

http://rosa-menkman.blogspot.com/search/label/Vernacular%20of%20File%20Formats

http://en.wikipedia.org/wiki/Procrastination

http://gwei.org/index.php | Google will eat itself